Я хотел бы знать, какие конкретные отличия между STL выпущены SGI и стандартная библиотека ISO С++. Под этим вопросом этот вопрос и вовсе не ответил на этот вопрос.
Некоторые различия очевидны, например, классы slist и hash_set, которые никогда не попадали в стандарт. Я также ищу более тонкие отличия, такие как различия в возвращаемых значениях/параметрах, методы или различные требования к сложности или разные условия аннулирования итератора.
SGI STL "отсутствует" в стандарте С++ включает
slistbit_vectorhash_set, hash_map, hash_multiset, hash_multimap и все, что относится к хеш-функциямropeiotalexicographical_compare_3wayrandom_sample и random_sample_nalgo.h... и я уверен, вы можете найти еще несколько.
В дополнение к тому, что larsmans уже написал:
std::basic_string получил интерфейс контейнера STL.
Некоторые функции шаблонов были добавлены в язык, чтобы лучше поддерживать STL, который может использовать STL-часть стандартной библиотеки, но недоступны для исходного STL.
operator[] in std::map имеет ту разность, что в стандарте он определяется как возвращающий (*((insert(make_pair(x, T()))).first)).second, тогда как в STL m[k] определяется как эквивалентный (*((m.insert(value_type(k, data_type()))).first)).second.
Разница в том, что соответствующие реализации С++ вызывают make_pair, тогда как STL напрямую конструирует пару. Я могу думать о двух различиях, которые это делает:
1) Стандарт допускает дополнительную копию пары (и, следовательно, объектов ключа и данных), если RVO не может выполнить вызов для make_pair. Когда я прочитал это, STL не разрешает эту копию (хотя, конечно, есть еще одна копия по строке, insert). Это имеет значение, если либо ключ, либо тип значения имеют конструкторы копирования с наблюдаемыми побочными эффектами.
2) Пользователи могут специализироваться либо std::make_pair, либо std::pair. Если они специализируются на make_pair, то их код гарантированно будет вызываться в стандартном С++ и гарантированно не будет вызываться в STL.
Такие специализации вызывают UB, если они не удовлетворяют требованиям шаблона, хотя, и в случае make_pair я думаю, что если он имеет какие-либо наблюдаемые эффекты, отличные от тех, которые создают пару, то он не " t удовлетворяют требованиям. Поэтому в этом случае может оказаться трудным или невозможным написать специализацию, гарантирующую, что вы сможете решить, было ли это вызвано или нет. На практике, если реализация сделала очевидную вещь и использовала код из стандарта, тогда вы легко увидите разницу...
Пользователи также могут ADL-overload make_pair, одинаковую оговорку, с дополнительным усложнением, которое я никогда не уверен, что упоминания в стандарте неквалифицированных вызовов функций требуют, чтобы реализация выполняла тот же безоговорочный вызов. Я уверен, что я слышал, что некоторые реализации сделали в этом случае полные вызовы std::whatever, возможно, ошибочно.
Это то, что вам нужно?
У STL также был некоторый функциональный материал, который был упущен в stdlib, хотя С++ 0x исправляет это.
Чтобы процитировать пример для составных fuctors из документа STL
Вычисляет sin (x)/(x + DBL_MIN) для каждого элемента диапазона.
transform(first, last, first,
compose2(divides<double>(),
ptr_fun(sin),
bind2nd(plus<double>(), DBL_MIN)));
Или, для пары селекторов:
transform(M.begin(), M.end(), ostream_iterator<double>(cout, " "),
select2nd<map<int, double>::value_type>());
В STL гарантируется, что версия с четырьмя аргументами std::list::splice имеет постоянную временную сложность, даже если часть одного списка сплавляется в другой список. Как следствие, std::list::size не гарантируется постоянная сложность, фактически гарантируется, что Omega (n), по крайней мере, в некоторых случаях. Я не проверял, делает ли реализация SGI ее Omega (n) во всех случаях.
В стандарте С++ 03 у 4-arg splice гарантируется только постоянная сложность, когда раздел списка перемещается в другое место в том же списке. Это означает, что размер списка не изменяется и, следовательно, позволяет реализации, в которых size() является постоянным временем. GNU придерживается подхода STL, но я считаю, что Dinkum выбрал постоянное время size().
В стандарте С++ 11 size() требуется постоянное время, и, следовательно, в действительности splice гарантируется, что Omega (n) в некоторых случаях. Метод STL больше не соответствует, и, как следствие, существует двоичная несовместимость в gcc, когда они добавили поле размера в std::list.
STL допускает возможность того, что реализация С++ не поддерживает шаблоны функций-членов (в этом случае все шаблоны функций-членов и шаблоны конструкторов недоступны). Очевидно, стандарт не позволяет этого.
Я не знаком с исчерпывающим списком. Однако можно получить исходный STL и сравнить его со стандартом, в зависимости от того, сколько времени у вас есть и сколько деталей вы хотите.