Всем привет!
Я тут подал предложение о введение PBDS из SGI STL в российскую национальную рабочую группу по стандартизации С++. Кто не в курсе -- это проработанный концепт сбалансированных бинарных деревьев, с достаточно гибкой возможностью поддержки метаданных в вершинах (см. здесь). Для нас наиболее видная особенность -- наличие встроенных order_of_key и find_by_order, которые отсутствуют в set и map. В случае добавления pbds в стандарт мы также можем ожидать, что там, наконец, починят merge и split, которые сейчас работают за 
вместо заявленных 
.
Предлагаю сообществу codeforces поучаствовать в обсуждении данного предложения.
UPD: Предложение на std-proposals.
Автокомментарий: текст был обновлен пользователем adamant (предыдущая версия, новая версия, сравнить).
Split и Merge в ropes?
В pb_ds. Здесь подробнее.
А какое у тебя обоснование надобности данной штуки более широкому кругу людей, нежели те, кто могут воспользоваться SGI STL? Я про такое, с которым ты будешь готов прийти на заседание комитета и сказать: "Чуваки, вот эта штука сильно улучшит жизнь разработчиков, если мы внесём её в стандарт".
Автору блога либо нужно опять поднять вклад, либо просто надоело подключать "особые" библиотеки.
Да прост нормальный спит-мердж хочу))
Ну контесты же удобнее будет писать, ну ты чего?
Auto comment: topic has been translated by adamant (original revision, translated revision, compare)
It is a great proposal but I don't think that it will be a successful one. The standard is kept as clear and simple as possible so adding a lot of data structures might break this idea.
STL should be useful, not simple.
That's wrong on many levels. Every single piece of code in the C++ standard must be maintainable and possibly upgradable (see move semantics for example). It is very hard to maintain a large number of containers so don't expect any new data structure in the near future (there are much more useful containers like
dynarraywhich are not ready yet so I don't expect to see tries any time soon)Absolutely agree!!!
The find_by_order() and order_of_key() should be added to set, map. I do not want to make a long declaration to have exactly the same set structure with only two more functionality.
And I don't want to spend precious processor time to update counters I'll never use if I don't use find-by-order or orderofkey
Absolutely agree!!!
The find_by_order() and order_of_key() should be added to set, map. I do not want to make a long declaration to have exactly the same set structure with only two more functionality.