Qlibs++ — header-only библиотеки для C++20

монстр типа loki или прям ок?

Нет, только reflect чуть больше 100 Kb.

mph

https://github.com/serge-sans-paille/frozen – похожая, для C++14.

Откуда интересно эта мода на header-only библиотеки, оно же по идее адски увеличивает время компиляции.

P.S. firkax, что тебе не нравится?

увеличивает время компиляции

Зато лучше оптимизируется.

Меня не прекращает умилять святая вера крестанутых в компилятор

Не вера, а знание. Проходи мимо.

Откуда интересно эта мода на header-only библиотеки, оно же по идее адски увеличивает время компиляции.

Если библиотека вся сплошь на шаблонах (а большинство перечисленных в стартовом сообщении, полагаю, именно такие), то пока C++ные модули не внедрят повсеместно другого выхода-то и нет.

увеличивает время компиляции

Зато лучше оптимизируется.

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

Отсюда же, кстати, мода на amalgamation.

В первую очередь

Не соглашусь. :)
GLM, например, будет работать быстрее с -march=<...>. Или std::simd.

Сколько ядер и гигабайт памяти нужно для работы с сабжем?

Мода пошла из шаблонной магии: ты шаблонную функцию по-другому не напишешь, кроме как в хидере. Либо указывать все возможные инстансы, что неудобно.

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

Для виндузятников, главным образом

Отсюда же, кстати, мода на amalgamation.

Amalgamation часто позволяют нехило сократить размер бинарника. Во времена, когда LTO было только в интеловском компиляторе, это было очень ценно.

Для виндузятников, главным образом

Виндузятники буквально добавили папку с исходниками в проекте студии и погнали. 9 из 10 без студии не могут скомпилировать проект.

Это в попенсурсе вечна борьба автолулзов с симейком помноженная на месонониньзю, а снизу-сбоку на всё это смотрит ошалевшими глазами GNU make.

P.S. @firkax, что тебе не нравится?

Среди перечисленного есть несколько условно-полезных штук, но в целом там сплошное ненужно.

То есть, если запрос к бд у тебя 5-10мс, но вот метод который этот запрос вызвал на 5 наносекунд быстрее, это чем то поможет?

Не одними БД живут программисты.

Не все программы состоят из перевода результата sql в json ответ. Иногда перед, или после работы с БД методов вызывается намного больше чем сам ответ, иногда БД нету, иногда твой код это БД.

Если скорость работы кода программы некритична (например, если это формирование запросов к БД), то не надо её писать на Си++.

Да, иногда программы ждут сеть, иногда диск… А из того что я вижу, с/с++ программисты заморачиваются на такты процессора. Всегда. Даже если прога – просто калькулятор. Да, иногда это важно, согласен.

если критична - тоже не надо, т.к. надо писать на ассемблере и сишечке

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

или можно сразу всё писать на лиспе

Ох уж эти знаменитые числодробилки на Лиспе!

суслика видишь?

пора вылезать из своего ограниченного крестового мирка то

Сишечка медленнее, чем Си++. Оптимизации ассемблера тоже нынче компилятор Си++ делает заметно лучше, чем среднестатистический программист.

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

Но итог работает медленнее. Поэтому если скорость действительно важна, приходится на крестах.

суслика видишь?

Судя по успешности и распространенности высокопроизводительного софта на Лиспе, могут увидеть его не только лишь все.

пора вылезать из своего ограниченного крестового мирка то

Зачем? Чтобы писать числодробилки на Лиспе?

Прассыти, я не настолько мазохист.

Особенно забавно это слышать от лишпера, вынужденного зарабатывать себе на жизнь C#.

Почему медленнее? Если ты пишешь на встроенном ассемблере SBCL, на VOP - с чего он должен быть медленнее?

Сишечка медленнее, чем Си++

Что за бред?

Зачем? Чтобы писать числодробилки на Лиспе?

Ты лисп в глаза не видел. С чего ты взял что на нем нельзя писать числодробилки, как и прочую лажу, которую ты пишешь на крестах?(исключая поддержку легаси на самих же крестах, ессно)

мазохист

Ты на крестах пишешь, это же надо быть не просто мазохистом, это психически больным надо быть вообще.

Ты лисп в глаза не видел.

И?

Я и COBOL-а толком не видел, как и Лисп-а. Что не мешает мне иметь мнение о его применимости. Как и о применимости каких-нибудь REXX или RPG.

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

Потому что я не вижу числодробилок на Лисп. И даже не слышу про таковые.

Вот когда какой-нибудь Lightroom будет на Lisp-е, а для больших расчетов перестанут применять OpenMP и MPI, вот и тогда и приходите с рассказами про могущество Lisp-а.

И?

Как ты можешь рассуждать о чем-то, чего не видел вообще, и о чем не имеешь понятия?

Что не мешает мне иметь мнение о его применимости

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

Как ты можешь рассуждать о чем-то, чего не видел вообще, и о чем не имеешь понятия?

Не «видеть вообще» и «не иметь понятия» – это разные вещи.

Я не изучал Lisp и не писал на нем программы. Но понятие имею.

Как и об упомянутых выше COBOL и REXX.

А вот вы, хоть и изучали C++, о нем понятия не имеете.

ЗЫ. Так что там на счет известных числодробилок на Lisp-е? Их хоть сколько-то нашлось за время нашего разговора?

mph – статические (минимальные) идеальные хеш-функции;

Чем это отличается от обычного ассоциативного массива и зачем назвали как-то по-другому?

Когда-нибудь плюснутые наконец осилят модули и пакетный менеджер и во всех этих header-only библиотеках пропадёт смысл.

Ты так и не смог объяснить, почему, если лишп такой охрененный и универсальный, GC в SBCL написан на сишке, а не на лишпе?

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

Когда-нибудь плюснутые наконец осилят модули и пакетный менеджер

Менеджер должен быть один - менеджер, который уже есть в ОС, а не ворох поделок для каждого язычка. Вот какой-то универсальный слой совместимости со всеми вариациями менеджеров в нормальной системе сборки, а не cmake дерьме (которое нужно закопать) - действительно нужен

Менеджер должен быть один - менеджер, который уже есть в ОС

И ОС тоже должна быть всего одна.

И пользователь должен быть один. На весь мир, да.

О, я вижу вы понимаете!

Ирония вообще не к месту. Менеджер ОС это по сути и есть сишный/++ менеджер, и исходники устанавливаются с сишным апи, к чему что-то изобретать? Товарищ предлагает компилять всё в некие универсальные модули и хранить их централизованно. Ненужно, бинари подтягиваются менеджером, а исходники гитом каким-нибудь. Нужна лишь нормальная система сборки вместо cmake’a.

Всякие петухоны через менеджер свою скриптуху тянуть не должны, конечно.

Добавил ссылку на Вики.

Чем это отличается от обычного ассоциативного массива

Делает примерно то же, что и GNU gperf, но во время компиляции.

зачем назвали как-то по-другому?

Чтобы из названия было понятно, каким методом вычисляется хеш.

Честно говоря понятнее не стало. Зачем для этой задачи отдельное узкое решение? Чем map<string, int> не угодил?

От того что мы фиксируем тип значения в численный тип, она разве становится хоть сколько нибудь более оптимально-вычисляемой?

Дело в коллизиях. В идеальных хеш-функциях их нет, в минимальных идеальных – одна запись на ключ.
Вышеупомянутый Frozen основан на Throw away the keys: Easy, Minimal Perfect Hashing.

Дело в коллизиях.

Это понятно. Но ведь не использовать одно значение два раза в ассоциативном массиве - тривиальная задача. Так что даёт это ограничение?

Просто скомпилируй бенчмарки Frozen. :)

vcpkg уже существует, и даже поддерживается всеми IDE

а когда скриптуха научится в системные библиотеки?

Чем map<string, int> не угодил?

На больших объемах данных, скорее всего, будет работать медленнее, чем хэш-таблица.

бенчмарки Frozen

---------------------------------------------------------------------
Benchmark                           Time             CPU   Iterations
---------------------------------------------------------------------
BM_IntInFzSet                    66.8 ns         66.8 ns     10245930
BM_IntInStdSet                    136 ns          136 ns      5029406
BM_IntInStdArray                  116 ns          116 ns      6033038
BM_IntNotInFzSet                 72.5 ns         72.5 ns      9618018
BM_IntNotInStdSet                 145 ns          145 ns      4811610
BM_IntNotInStdArray               172 ns          172 ns      4082452
BM_StrInFzSet                     389 ns          389 ns      1805442
BM_StrInStdSet                    499 ns          499 ns      1389587
BM_StrInStdArray                  478 ns          478 ns      1481770
BM_StrNotInFzSet                  287 ns          287 ns      2441268
BM_StrNotInStdSet                 434 ns          434 ns      1626321
BM_StrNotInStdArray               645 ns          645 ns      1076738
BM_StrInFzUnorderedMap            315 ns          315 ns      2229108
BM_StrInStdUnorderedMap           505 ns          505 ns      1351129
BM_StrNotInFzUnorderedMap         189 ns          189 ns      3632317
BM_StrNotInStdUnorderedMap        558 ns          558 ns      1244232
BM_IntInFzUnorderedSet            157 ns          157 ns      4512121
BM_IntInStdUnorderedSet           260 ns          260 ns      2707195
BM_IntInStdArray                  116 ns          116 ns      5980369
BM_IntNotInFzUnorderedSet         111 ns          111 ns      6315264
BM_IntNotInStdUnorderedSet        286 ns          286 ns      2415577
BM_IntNotInStdArray               180 ns          180 ns      3817437
BM_StrInFzUnorderedSet            314 ns          314 ns      2203293
BM_StrInStdUnorderedSet           509 ns          509 ns      1327442
BM_StrInStdArray                  472 ns          472 ns      1479975
BM_StrNotInFzUnorderedSet         189 ns          189 ns      3626886
BM_StrNotInStdUnorderedSet        556 ns          556 ns      1240116
BM_StrNotInStdArray               646 ns          646 ns      1062831