Какие контейнерные библиотеки для C++ вы бы хотели (а не вынуждены) использовать

Новорачиванием новых фич, удачные они или нет, усложнением компиляторов в разы, изменением семантики, поломкой обратной совместимости.

На текущий момент около 50% пользователей ЛОРа пишет на C++. Можно в дальнейшем предполагать, что пользовати ЛОРа этот язык знают. Т.е. не описывать проблему завуалированно, а просто показывать конкретную строчку, где был баг.

Не пишу на C++, потому что вообще не программист. Мне кажется этот вариант знатно исказит результаты.

стандартных классов хватает. правда я пишу на с++ только серверные приложения.

это «много или мало» что определяет ?

На усмотрение эксперта.

ну очевидно Qt4 хорош,после него stl11, буст имхо какая-то оверпереоцененная штука, еще и дико неудобная

QtCore 4+. Других я никогда и не использовал.

А вот про abseil и folly я, честно говоря, слышу впервые. Поделишься опытом?

Это всё про бек-энд, есть пилишь гуи – не нужно.

abseil это дополнение std:: с точки зрения google, folly – то же самое с точки зрения facebook. То же самое есть и от кучи (почти всех скорее даже) других крупных контор, вроде yandex или bloomberg, но по-моему их стдлибы популярность в народе не получили.

abseil переделывали с нуля и перфекционизмом, поэтому он маленький и не полон фич. Годится как шаблон для нового проекта, который хочет следовать практикам Google SWE book.

folly я так понимаю полная вырезка внутренних либ фейсбука, поэтому там много интересного. Но местами реализовано не идеально. Из полезного – hazard pointers, token bucket и iobuf. Например, их AsyncUDPSocket умеет в GSO offload, что во всяких boost asio вроде как нет. Очень практичная либа, без задротства с шаблонами, всё по делу, но иногда хочется больше прилизанности.

Я на C++ только код порчу.

А вот про abseil … слышу впервые

Google/RE2 теперь зависит от Abseil, но в Debian/Devuan пока старая версия.

abseil … маленький

Почти 10Mb исходников, это не маленький.

Даже у меня на гитхабе есть консольная утилита, использующая QtCore. Но там основным мотивом, конечно, было то, чтобы у консольной и графических программ была единая кодовая база. С человеческими юникодными строками в том числе. Специфический случай, да.

Я такой же деревенский.

Контейнеры в STL на удивление норм, но в Qt все равно удобнее немного.

А где вариант «Вы вообще о чем?»

Просто пишите на старом добром Си, а не обмазывайтесь плюсами с их раздутостью и непостоянством стандартов. И тогда ваш код будет хоть через сто лет работать!

wxWidgets тут все-таки мимо. Один из вариантов компиляции этой библиотеки - использовать STL, при этом встроенные в библиотеку классы контейнеров выступают только как синтаксический сахар.

Если писать на C++98, то никаких проблем не будет. Такая же классика, как ANSI C.

Со строками (в общем случае мультиязычными) уже можно работать без боли?

Нет. std::codecvt deprecated в c++20, а альтернативы не завезли.

А я юзаю вот это (нашёл здесь). Обратное преобразование тривиально, навелосипедил сам.
Ничего другого на линуксе не требуется, т.к. sizeof(wchar_t) == 4.

Я собственно чего зашёл:

Не пишу на C++ 147 (56%)

Стыд и позор, господа! Кто вас вообще сюда пустил?!

Стыд и позор — это то, что кресты до сих пор имеют популярность. 147 (а точнее уже 150) это не стыд и позор, а честь и совесть, если они пишут на других языках, включая просто C.

Выгдядит суперминималистично. Оно работает? И оно для преобразования из utf16 в utf8 ?

непостоянством стандартов

Вот этот аргумент я читал недавно в теме про ненужность интов более байта. Так вот были там два идиота (cumvillain и khrundel), и один из них, не помню точно, кто именно утверждал: «сейчас это не ub, а завтра стандарты перепишут и будет ub», «а вот елси завтра …».

Так вот, во первых стандарт не поменяется, выйдет новый стандарт. А старый стандарт останется закрепленным. И тебе никто не мешает продолжать использовать старый стандарт. Вот C++98 до сих пор компиляторы поддерживают. И ничего не случилось. Можно конечно сказать: «ну а если выйдет новый стандарт, а все старые дропнут» - на что я могу ответить, что исходя из прошлого опыта такая вероятность невелика.

Из utf8 в unicode (оно же utf32); utf16 на линуксе не нужен.

для преобразования из utf16 в utf8

https://github.com/nemtrif/utfcpp, например.

Ну https://github.com/simdutf/simdutf, если важна скорость.

Выгдядит суперминималистично.

Вот суперминималистично: https://nullprogram.com/blog/2017/10/06/ :)

А я юзаю вот это

Усовершенствованно: utf8_decode.c

utf16 на линуксе не нужен

Ну да ты че :-) Потому что ты так решил? Тем более я занимаюсь разработкой кроссплатформенного по.

Я сказал «на линуксе», ты мне «кроссплатформенным по» тычешь. Тебе про Фому, ты про Ерёму.

Потому что ты так решил?

Так решили те, кто сделал sizeof(wchat_t) == 4.

Кросс включает линукс. У нас на проекте все что справедливо для общей группы (lin/mac/win) справедливо и для каждой отдельной.

Ну т.е. твое «не нужно на линуксе» - слишком уж понтово. Тебе может быть и не нужно. Но только много кому нужно.

sizeof(wchat_t)

А что, на этом типе свет клином сошелся? У нас он после появления std::u16string и char16_t не используется.

Кросс включает линукс.

Включает линукс != только линукс. Ты нарочно демагогию гонишь, или правда к простейшей логике не способен?

Но только много кому нужно.

Кому-то и похапэ нужен. И js на сервере. И раст в ядре. И смазка анальная.

А что, на этом типе свет клином сошелся? У нас он после появления std::u16string и char16_t не используется.

В 32 бита влезает любой unicode-символ, а 16 бит – ни туда, ни сюда: ни константного размера символа, ни эффективности по памяти. Разве что вы сознательно порезали смайлы или что там в верхних диапазонах, т.е. получили и константный размер символа, и компромисс по памяти (4 байта на символ – это всё-таки дичь) ценой по сути неполноценной поддержки юникода. Костыль поверх костыльной utf16.

Не пишу на C++ 147 (56%)

Моё уважение, коллеги!

Включает линукс != только линукс. Ты нарочно демагогию гонишь, или правда к простейшей логике не способен?

Если нам на проекте нужно именно utf16, а проект на lin/mac/win, то значит нам нужно и на linux тоже. У тебя самого с логикой проблемы?

Кроме того хочу заметить, что ПО на linux как частенько кроссплатформенное, имею ввиду всякий пользовательский софт.

Кому-то и похапэ нужен. И js на сервере. И раст в ядре. И смазка анальная.

Если ПХП нужен, а кстати он нужен, то и хорошо. И не нужно за других решать. Про анальную смазку не скажу, не практиковал.

В 32 бита влезает любой unicode-символ, а 16 бит – ни туда, ни сюда: ни константного размера символа, ни эффективности по памяти… … ценой по сути неполноценной поддержки юникода. Костыль поверх костыльной utf16.

А что ты подразумеваешь под полной поддержкой? Ты лучше напиши, что нельзя сделать с utf16 такого, что можно с utf32 ?

Разве что вы сознательно порезали смайлы или что там в верхних диапазонах Какой конкретно диапазон не влез? Там точно часто используемые cимволы? Допускаю, что и хер бы с ними.

Ты лучше напиши, что нельзя сделать с utf16 такого, что можно с utf32 ?

Лексикографическая сортировка
Быстрое получение кодпоинтов без декодирования
Всё это на utf16 можно сделать быстро, но некорректно. Если его обрабатывпть корректно - то никаких преимуществ перед utf-8 не будет, зато будет сильно медленнее чем на utf32 где это делается в лоб

На самом деле -std=c++98 сейчас означает то же, что и -std=c++03. По крайней мере у шланга и гцц. Но C++03 не ломает C++98, скорее наоборот определяет поведение того, что раньше вовсе не было описано.

Быстрое получение кодпоинтов без декодирования

Ну да, ну да. А там что, много операций при раскодировании?

Лексикографическая сортировка

А почему нельзя то? Просто нужно сравнивать код из юникода.

Это ты к чему? Не очень понял вывод.

Ну да, ну да. А там что, много операций при раскодировании?

чтобы достать i-тый кодпоинт теюе придётся декодировать весь поток до i включительно, как и в случае с utf-8.

А почему нельзя то? Просто нужно сравнивать код из юникода.

Чтобы получить код юникода из utf-16 его надо декодировать.
utf-8 и utf-32 позволяют массив просто сравнивать поэлементно, utf-8 так устроен, что порядок совпадёт, utf-16 - нет

Чтобы получить код юникода из utf-16 его надо декодировать.

Чтобы понять, что число является частью суррогатной пары в utf16 декодировать не нужно. Т.е. пропустить например первые 5 символов можно без их раскодирования.

Ну про то, что компиляторы не поддерживают C++98, только C++03.

Т.е. при передаче флага c++98 gcc будет вести себя как при передаче c++03 ? Не знал такого. А есть где про это почитать?

Но проверять придётся. Получается O(n) а не O(1) уже

O(n)

При проверке на сурогатность и при раскодировании требуемого по счету символа разные действия.

всё равно время будет зависеть от длины строки

https://gcc.gnu.org/onlinedocs/gcc/Standards.html#C_002b_002b-Language

перепись тулкитофобов и велосипедистов :)

А ну тут все понятно: c++03 не внес изменений в язык, а являлся исправлением ошибок. Ну да, убрал ub при value initialization. Т.е. уже существующий код не был сломан.

В Kotlin работа с контейнерами ещё лучше и удобнее сделана. Хотя наверное у LINQ пошире возможности, это ещё и DSL.

Я тут узнал, что в плюсы(С++20) завезли подобие Linq - std::views. Синтаксис конечно немного не так красив, но по возможностям уже неплохо(хоть пока и не дотягивает до Linq).