Комментарии 12
Почему бы не упомянуть boost::container::flat_map и иже с ним? Как они соотносятся и всё такое. Ведь сразу же возникает вопрос, что использовать: реализацию из boost или из std.
А что, в std из ниоткуда приходит, не из boost, как это обычно было? Удивительна жалоба автора, что он "не может продемонстрировать бла-бла-бла, поскольку ни один компилятор их не поддерживает" – ведь это часть библиотеки, а не компилятора, и раз пришло в стандарт – значит, уже есть референсная реализация, которая должна работать на нынешних компиляторах.
Если есть в std то я бы использовал из std. Если нет в std, но есть в бусте, то я бы все равно не использовал буст, так как есть куча standalone реализаций flat_map'ов, которые не тянут с собой ничего и содержатся в одном заголовочном файле. Возможно, я статью плохо прочитал, но не увидел что конкретно означает "плоский контейнер" и не увидел картинку с хэшем с открытой адресацией.
В absl тоже есть. Для тестов производительности вполне можно использовать, Гугл их наверняка хорошо оптимизировал.
Очередная статья о программировании без программирования:)
Блин, штука иногда полезная, но узкая, да и вроде же это все можно в одном заголовке делать. Зачем только всего в стандартной библиотеке?
являются полноценной заменой упорядоченных ассоциативных контейнеров
Хм, я бы так не сказал. Полноценная замена это когда можно взять старый контейнер и не думая заменить на новый. Если бы это было так, не надо было бы делать новый тип - можно просто сменить реализацию.
Но новые классы потому и существуют, что изменив API и отменив некоторые гарантии стабильности итераторов и указателей, удалось добиться лучшей производительности когда эти гарантии не нужны.
Дичь что они стандартизовали flat_map с друзьями до flat_hash_map и коллег. Первый довольно ограниченный в применимости тип, иногда улучшает производительность по сравнению с map, иногда страшно ухудшает. Второй практически всегда (если не нужна стабильность итераторов) улучшает ситуацию по сравнению с unordered_map. Но похоже его по прежнему придется из absl использовать.
Что только ни добавят в стандарт, лишь бы не стандартизацию внешних зависимостей</сарказм_с_болью>
На контрасте с Go с превосходными зависимостями, но невозможностью сделать свой полноценный контейнер (operator[] только для встроенных типов). Спасибо generic - очень сильно упростился этот момент.
C++98 --> C++11--> вот здесь вы не раскрыли тему C++17 std::pmr::... --> C++23
Считайте, что тогда уже появился а-ля std::flat_list ;-)
Вот здесь даже посчитали на сколько какой способ быстрее https://en.cppreference.com/w/cpp/memory/monotonic_buffer_resource
C++23: четыре новых ассоциативных контейнера