原來的STL和那些以C++標準庫結尾的部分之間有什麼特定的區別？

我想知道SGI發佈的STL與ISO C++標準庫之間的具體區別。由this question提示，完全沒有回答this question。原來的STL和那些以C++標準庫結尾的部分之間有什麼特定的區別？

有些區別是顯而易見的，如slist和hash_set類，從未進入的標準。我還在尋找更細微的差異，例如方法上的返回值/參數差異，或不同的複雜度要求，或不同的迭代器失效條件。

2011-03-10 Mark Ransom

的可能重複[有什麼標準庫和標準模板庫之間的區別？（http://stackoverflow.com/questions/4064010/what-is-the-difference-between-the-standard-library -and-the-standard-template-lib） – 2011-05-06 08:46:16

@Fred：__No，那是錯的！不要關閉/合併！__ – sbi 2011-05-06 08:51:22

這個問題有一個有點誤導性的標題。（我現在固定的），它的目的是爲了索要___original STL___並得到了___incorporated到標準library___它的那些部分之間的___specific differences___。 – sbi 2011-05-06 08:52:12

除了什麼larsmans already wrote：

std::basic_string得到了配有一個STL容器接口。
爲了更好地支持標準庫的STL部分可以利用的STL，但不能用於原始STL的STL中添加了一些模板功能。

來源

2011-03-10 21:58:25 sbi

正確，我不是在尋找歷史課 - 這已經在別處討論過了。 – 2011-03-10 22:13:41

@Mark：改變了我的答案。 HTH。 – sbi 2011-03-10 22:21:34

SGI STL的東西，在C++標準「缺失」包括

slist
bit_vector
hash_set，hash_map，hash_multiset，hash_multimap和一切有關散列函數
rope
iota
lexicographical_compare_3way
random_sample和random_sample_n
的MonoidOperation和Trivial Iterator概念
向後compat的頭，比如algo.h

的主人...我敢打賭，你可以找到幾個更多。

來源

2011-03-10 22:08:34

值得注意的是，其中的一些是在tr1中，並將在C++ 0x :-)。 – 2011-03-11 00:40:12

'hash_anything'不是任何C++標準，但是被編譯器廠商廣泛提供。這就是哈希表不能在C++中使用該名稱的原因0x – sbk 2011-03-11 10:35:10

@sbk：它們的一個版本（'unordered _...'）將成爲下一個C++標準的一部分。 – sbi 2011-03-11 14:47:57

STL也有一些功能的東西，遺憾的是在stdlib中錯過了，雖然C++ 0x修復了這個問題。

引述an example爲組合物fuctors從STL DOC

計算爲一系列中的每個元素的sin（x）/（X + DBL_MIN）。

transform(first, last, first, 
      compose2(divides<double>(), 
        ptr_fun(sin), 
        bind2nd(plus<double>(), DBL_MIN)));

或者，pair selectors：

transform(M.begin(), M.end(), ostream_iterator<double>(cout, " "), 
      select2nd<map<int, double>::value_type>());

來源

2011-03-16 14:42:29 Cubbi

operator[]在std::map具有在標準它被定義爲返回(*((insert(make_pair(x, T()))).first)).second，而在STL m[k]被定義爲等同於(*((m.insert(value_type(k, data_type()))).first)).second的差異。

區別在於符合C++的實現調用make_pair，而STL直接構造該對。我可以想到兩個不同之處：

1）如果RVO未能接聽make_pair的呼叫，則該標準允許該配對的副本（以及因此的密鑰和數據對象）。當我閱讀它時，STL不允許這個副本（儘管當然在insert下有更多的副本）。如果鍵或值類型的副本構造函數具有可觀察的副作用，則這很重要。

2）用戶可以專注於std::make_pair或std::pair。如果他們專門致力於make_pair，那麼他們的代碼將保證在標準C++中調用，並保證不會在STL中調用。

這樣的專業化會導致UB，如果它們不滿足模板的要求，並且在make_pair的情況下，我認爲如果它具有除創建對之外的任何可觀察效果，則它不會滿足要求。因此，在這種情況下可能很難或不可能寫出保證的專門知識，以便確定它是否已被調用。在實踐中，如果執行做了明顯的事情，並使用從標準的代碼，那麼你會很容易看到一個區別...

用戶還可以ADL過載make_pair，同樣需要注意，與額外的併發症，我m不太確定提及非標準函數調用的標準是否要求實現進行相同的非限定調用。我確定我聽說有些實現已經在這種情況下完成了對std::whatever的調用，可能是錯誤的。

這是你之後的事情嗎？

來源

2011-05-12 22:47:18

是的，這將是我正在尋找的一個例子。非常極端的例子，因爲你不可能在實際代碼中看到不同。 – 2011-05-13 21:04:13

-1

我並不熟悉詳盡的列表。但是，有可能get the original STL並將其與標準進行比較，具體取決於您有多少時間以及需要多少細節。

來源

2011-05-12 23:09:00

我希望問這個問題的是有人已經這樣做，並願意分享。到目前爲止，只有很少的東西不會像在快速閱讀中那樣跳出來。 – 2011-05-12 23:40:09

這是我的預感（你希望有人已經寫過的詳盡列表，即「更細微的差異，例如方法上的返回值/參數差異，或不同的複雜度要求，或不同的迭代器失效條件」），以及larsmans的回答是我見過的最長的名單，但並不全面。 – 2011-05-13 20:54:21

我並不是真的期望得到一個詳盡的答案，而是來自不同貢獻者的點點滴滴，當他們合在一起時，這些點點滴滴就是全面的。 – 2011-05-13 20:59:02

在STL中，std::list::splice的四參數版本保證具有恆定的時間複雜度，即使一個列表的一部分被拼接到不同的列表中。因此，std::list::size不保證具有恆定的複雜性，實際上至少在某些情況下實際上保證爲歐米茄（n）。我沒有檢查SGI的實施是否在所有情況下都使用Omega（n）。

在C++ 03標準，4- ARG splice只保證具有恆定的複雜性時的列表的部分被移動到不同的位置在同一列表。這意味着列表的大小不會改變，因此允許size()是恆定時間的實現。 GNU堅持STL方法，但我相信Dinkum選擇了恆定時間size()。

在C++ 11標準中，size()需要具有恆定的時間，因此在某些情況下實際上splice保證爲歐米茄（n）。 STL方法不再符合，因此當他們將大小字段添加到std::list時，gcc中存在二進制不兼容性。

來源

2012-11-01 08:57:13

的STL允許該C++實現不支持成員函數模板（在這種情況下，所有的成員函數的模板和模板的構造是不可用的）的可能性。顯然這個標準不允許這樣做。

來源

2012-11-05 10:34:03

原來的STL和那些以C++標準庫結尾的部分之間有什麼特定的區別？

回答

相關問題