LINUX.ORG.RU
Голосования — Голосования  

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

 ,


0

2

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

  1. Не пишу на C++ 224 (58%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. STL, современный, С++11 и выше 114 (29%)

    ******************************************************************************************************************************************************************

  3. QtCore, современный, версии 4+ (напишу в комментариях) 60 (16%)

    *************************************************************************************

  4. Boost C++ libraries, новый 32 (8%)

    *********************************************

  5. Все плохо, нужно писать свое 26 (7%)

    *************************************

  6. STL, классический, C++98 23 (6%)

    ********************************

  7. Все плохо, контейнеры не нужны 18 (5%)

    *************************

  8. wxWidgets 13 (3%)

    ******************

  9. Boost C++ libraries, старый, когда он был еще "маленьким" 6 (2%)

    ********

  10. Qt, классический, версии 1-3 (напишу в комментариях) 4 (1%)

    *****

  11. Свой вариант (напишу в комментариях) 4 (1%)

    *****

  12. Watcom / OpenWatcom C++ classes 2 (1%)

    **

Всего голосов: 526, всего проголосовавших: 387

★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 7)

 ← 1 2 3 →
Ответ на: комментарий от aol

А ничего, что STL просто дико блоатит код, если, например, начать использовать несколько векторов от разных типов?

Мне вот, например, «дико оптимизированный» inline-обход вектора не нужен, я готов потратиться на call функции, которая достанет элемент из контейнера по нужному индексу.

А учитывая, что все элементы - это указатели на различные объекты, которые можно генерализовать до void *, то весь код всех контейнеров укладывается в несколько десятков килобайт машинного кода, обёрнутого шаблонами, которые тупо кастят финальный тип указателя в void * и назад, и ничего не блоатится.

sadko4u ★★
()
Ответ на: комментарий от mittorn

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

Не совсем корректно. UTF-8 позволяет, например, любой ASCII-символ записать как в однобайтовом, так и в двух, трёх, четырёхбайтовом варианте. Это значит, что strcmp у вас не отработает, если какой-нибудь хитрый пользователь решит не совсем стандартные кодпоинты подать на вход.

sadko4u ★★
()
Ответ на: комментарий от sadko4u

А это вообще будет считаться корректным utf-8?
С точки зрения декодера проблем не вижу, но не нарушает ли такая неоднозначность формат?

mittorn ★★★★★
()
Ответ на: комментарий от sadko4u

кстати, это можно было бы реализовать в виде общей имплементации для всех указателей, чтобы различающаяся часть инлайнилась

mittorn ★★★★★
()
Ответ на: комментарий от sadko4u

Только надо подумать как передать тип для operator new.

zx_gamer ★★
() автор топика
Ответ на: комментарий от sadko4u

А ничего, что STL просто дико блоатит код, если, например, начать использовать несколько векторов от разных типов?

«Какие ваши доказательства»?

Мне вот, например, «дико оптимизированный» inline-обход вектора не нужен, я готов потратиться на call функции, которая достанет элемент из контейнера по нужному индексу.

Делаю ставку на то что вы в подавляющем меньшинстве.

bugfixer ★★★★
()

Писал на С++ больше 10 лет, но 8 лет назад перешел на мобильную разработку и практически C++ больше в повседневной работе не нужен. А так до этого если проекты были для компов, то STL использовался и отдельные либы из Boost. А если приходилось писать для эмбеддед систем, то вообще темплейты избегали использовать. Просто использовали классический С++. Фактически С с классами больше для лучшего упорядочивания кода и для типизации так как темплейты увеличивали код и было сложно уложиться в 1 мегабайт флеш памяти. А иногда память ограничивалась и 256 килобайтами.

Grindz ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 →
Голосования