Каковы конкретные различия между исходным STL и теми его частями, которые оказались в стандартной библиотеке C ++?

Question

Я хотел бы знать, в чем заключаются конкретные различия между STL, выпущенным SGI , и стандартной библиотекой ISO C ++. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *.это в стандарт.Я также ищу более тонкие различия, такие как разность возвращаемых значений / параметров в методах, или другие требования к сложности, или другие условия аннулирования итератора.

Answer 1

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 и Тривиальные итераторы концепции
• множество заголовков обратного компатации, таких как algo.h

... и, держу пари, ты найдешь еще несколько.

Answer 2

В дополнение к тому, что larsmans уже написал :

• std::basic_string получил интерфейс контейнера STL.

• Некоторые функции шаблонов были добавлены в язык для лучшей поддержки STL, которую STL часть стандартной библиотеки может использовать, но не было доступно для оригинального STL.

Answer 3

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, то же самое предостережение, с дополнительнымсложность в том, что я не совсем уверен, требуют ли упоминания в стандарте вызовов без оговорок, чтобы реализация выполняла тот же неквалифицированный вызов.Я уверен, что слышал, что некоторые реализации в таких случаях совершали полные вызовы std::whatever, возможно, ошибочно.

Это то, что вам нужно?

Answer 4

STL допускает возможность того, что реализация C ++ не поддерживает шаблоны функций-членов (в этом случае все шаблоны функций-членов и шаблоны конструктора недоступны). Очевидно, что стандарт этого не допускает.

Answer 5

В STL версия с четырьмя аргументами std::list::splice гарантированно будет иметь постоянную временную сложность, даже когда часть одного списка объединяется в другой список. Как следствие, не гарантируется, что std::list::size будет иметь постоянную сложность, фактически гарантированно будет Omega (n) по крайней мере в некоторых случаях. Я не проверял, делает ли реализация SGI Omega (n) во всех случаях.

В стандарте C ++ 03 4-arg splice гарантированно будет иметь постоянную сложность, только когда часть списка перемещается в другое место в том же списке . Это означает, что размер списка не изменяется, и, следовательно, учитывает реализации, в которых size() является постоянным временем. GNU придерживался подхода STL, но я считаю, что Динкум выбрал постоянное время size().

В стандарте C ++ 11 size() требуется иметь постоянное время, и, следовательно, в действительности splice гарантированно будет Omega (n) в некоторых случаях. Подход STL больше не соответствует, и, как следствие, в gcc есть двоичная несовместимость, когда они добавили поле размера к std::list.

Answer 6

STL также имел некоторые функциональные возможности, которые, к сожалению, отсутствовали в stdlib, хотя C ++ 0x исправляет это.

Цитировать пример для композиционных фукторов из STL doc

Вычисляет 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>());

Answer 7

Я не знаком с исчерпывающим списком.Однако можно получить исходный STL и сравнить его со стандартом в зависимости от того, сколько у вас есть времени и сколько деталей вы хотите.