https://github.com/p-ranav/awesome-hpp
Довольно большой список.
Table of Contents
Argument Parsers
Audio
Benchmarking
Communication
Compression
Concurrency
Cryptography and Security
Databases
Data Formats
Data Mining, Machine Learning, and Deep Learning
Data Formatting and Presentation
Data Querying
Data Structures and Algorithms
Debugging
Deep Learning
Dependency Injection
Event Handling Mechanisms
File System
Functional Programming
Geometry, Graphics Processing, and Game Development
GPU
Graph
GUI
High-performance Computing
HTTP and the Web
Image Processing
Language Bindings
Language Development
Logging
Mathematics
Memory Management
Mocking
Networking
Optimization
Parsing
Parsing Expression Grammars
Portability Definitions
Reflection
Regular Expression
Robotics
Serialization
SIMD
Standard/Support Libraries
State Machine
Statistics
String Utilities
Templating Engines
Terminal Utilities
Testing Frameworks
Unicode
Units
Validation
Web Frameworks
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
C++ вынуждает писать header-only библиотеки потому, что нормальной модульности в языке не предусмотрено, а с внешними библиотеками — слишком большой геморрой. Заложишься на какую-нибудь такую, а потом окажется, что в Федоре она есть, а в Убунте нет. И что с ней делать? С собой таскать мутрно, дистрибутивщиков замучаешься уговаривать библиотеку включить, да и если уговоришь, то включат тольно в следующей версии дистрибутива. Поэтому каждый раз приходится проводить исследования на предмет совместимости с дистрибутивами.
А так, сплошные минусы. Ладно еще, если это что-то компактное и простое, но тогда зачем его вообще включать? А если что-то большое и сложное, зачем мне 100500 копий одного и того же кода, размазанные по всему проекту?
Вообще, сама по себе концепция, что программист — это мастер по склеиванию чужого кода, порочна. Это приводит к деградации профессии. Народ просто люто, бешено боится писать новый, оригинальный код. Это прям позорнее, чем триппер подхватить, написать свой код, а не взять готовую библиотеку. И в результате, посмотришь на любой проект, это сплошные чужие библиотеки (в которых, конечно, никто всерьез не разбирается; поток управления уходит куда-то, а там — черный ящик и магия) и прослойки, которые слепляют всё это хозяйство. И отладчик, как основной инструмент разработчика, потому, что анализу это не поддается, а только трассировке.
Пусть этим склеиванием ChatGPT занимается, а не живой человек. У него, как раз, ума на это хватит.
Pzz>C++ вынуждает писать header-only библиотеки потому, что нормальной модульности в языке не предусмотрено, а с внешними библиотеками — слишком большой геморрой. Заложишься на какую-нибудь такую, а потом окажется, что в Федоре она есть, а в Убунте нет. И что с ней делать? С собой таскать мутрно, дистрибутивщиков замучаешься уговаривать библиотеку включить, да и если уговоришь, то включат тольно в следующей версии дистрибутива. Поэтому каждый раз приходится проводить исследования на предмет совместимости с дистрибутивами.
Абсолютно согласен.
Вот надеюсь на С++20.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
Pzz>>C++ вынуждает писать header-only библиотеки потому, что нормальной модульности в языке не предусмотрено, а с внешними библиотеками — слишком большой геморрой. Заложишься на какую-нибудь такую, а потом окажется, что в Федоре она есть, а в Убунте нет. И что с ней делать? С собой таскать мутрно, дистрибутивщиков замучаешься уговаривать библиотеку включить, да и если уговоришь, то включат тольно в следующей версии дистрибутива. Поэтому каждый раз приходится проводить исследования на предмет совместимости с дистрибутивами. LVV>Абсолютно согласен. LVV>Вот надеюсь на С++20.
Pzz>Вообще, сама по себе концепция, что программист — это мастер по склеиванию чужого кода, порочна. Это приводит к деградации профессии. Народ просто люто, бешено боится писать новый, оригинальный код. Это прям позорнее, чем триппер подхватить, написать свой код, а не взять готовую библиотеку. И в результате, посмотришь на любой проект, это сплошные чужие библиотеки (в которых, конечно, никто всерьез не разбирается; поток управления уходит куда-то, а там — черный ящик и магия) и прослойки, которые слепляют всё это хозяйство. И отладчик, как основной инструмент разработчика, потому, что анализу это не поддается, а только трассировке.
И тут абсолютно согласен.
Вот как мы в 80-е делали договор с морячками.
1. Включили в PL-1 элементы лиспа с помощью препроцессора (написали сами)
2. Написали уже полноценную статическую библиотеку вместо препроцессора, которую собирал уже линкер
3. Придумали язык программирования типа планнер, конннайвер (тогдашние языки сверхвысокого уровня)
4. На PL-1+лисп написали интерпретатор нового языка
5. На новом языке уже запрограммировали весь договор.
Фишка там была в том, что на языке писалась и модель парохода, и программы ее обрабатывающие.
на все ушло три года — от ТЗ до акта.
Сейчас бизнес 3 года ждать не хочет.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Вот надеюсь на С++20. Pzz>Молодое вино не вливают в ветхие мехи.
Поэтому просто переходим на Go.
Я вот 2 курсу (хотя это не предусмотрено никаким учебным планом) собираюсь основы Go преподать.
Лабы по С++ для 1 курса сделаем на Go, а для 2 курса ООП — на С++ и Go.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>3. Придумали язык программирования типа планнер, конннайвер (тогдашние языки сверхвысокого уровня)
А у тебя есть что-нибудь про планнер почитать? А то я слово слышал, но никаких документов по языку найти не смог.
LVV>Сейчас бизнес 3 года ждать не хочет.
Бизнес готов ждать и 33 года, но бизнесу хочется с самого начала иметь расписанный план с двухнедельной деталировкой. А то вдруг эти гады-программысты будут весь срок балду пинать, а под конец разбегутся. Или, что еще хуже, балду пинать не будут, а под конец разбегутся, прихватив наработки.
А оккуда ему взяться-то, этому детальному плану, на этапе, когда все еще только начинается и ничего непонятно?
Поэтому бизнес с легкостью берется за трудные вещи, вливая дополнительные ресурсы, но очень опасается сложных вещей, которых никто еще не делал (иначе сложное превращается в трудное путем копирования чужого).
Здравствуйте, LaptevVV, Вы писали:
Pzz>>Молодое вино не вливают в ветхие мехи. LVV>Поэтому просто переходим на Go.
На Go не напишешь драйвер или C-callable плагин. Придется, наверное все-таки на руст посмотреть, хоть от торчащих из него восклицательных знаков глаза колет.
LVV>Я вот 2 курсу (хотя это не предусмотрено никаким учебным планом) собираюсь основы Go преподать. LVV>Лабы по С++ для 1 курса сделаем на Go, а для 2 курса ООП — на С++ и Go.
Я заметил интересную вещь. Если есть какая-то библиотечка на Си и обертка к най на Go, то гошная автосгенеренная документация зачастую будет более всеобъемлющая, детальная и понятная, чем родная сишна. Прям вот вплоть до того, что можно вмести сишной гошную читать, даже если нужен именно вот Си.
LVV>>3. Придумали язык программирования типа планнер, конннайвер (тогдашние языки сверхвысокого уровня) Pzz>А у тебя есть что-нибудь про планнер почитать? А то я слово слышал, но никаких документов по языку найти не смог.
У меня самого нет — осталось все в Ташкенте.
НО можно найти в библиотеке.
В советской серии Библиотека программиста (с перфолентой на обложке по краю) она издавалась переводная.
Как сейчас помню обложка была красная.
В Ленинке наверняка есть
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, so5team, Вы писали:
Pzz>>Люблю и ценю телепатов. Всегда-то они лучше меня знают, что творится у меня в голове.
S>Вы внезапно изучили C++ и начали его использовать? Помнится, раньше вы говорили, что C++ не владеете и его не используете.
Это не означает, что я не в курсе, что в C++ делают темплейты. Но мне приятно Ваше внимание к моей скромной особе.
S>Или я могу предположить, что у вас в голове уже и деменция творится?
Люблю и ценю телепатов. Впрочем, я это уже говорил...
Здравствуйте, Pzz, Вы писали:
Pzz>Это не означает, что я не в курсе, что в C++ делают темплейты.
По меньшей мере вызывает сомнения.
Pzz>Но мне приятно Ваше внимание к моей скромной особе.
Я бы с удовольствием не обращал бы на вас внимание, если бы вы не несли ахинею касательно языка, которого не знаете. Но вы почему-то это делаете с завидным упорством.
Здравствуйте, LaptevVV, Вы писали:
Pzz>>C++ вынуждает писать header-only библиотеки потому, что нормальной модульности в языке не предусмотрено, а с внешними библиотеками — слишком большой геморрой. Заложишься на какую-нибудь такую, а потом окажется, что в Федоре она есть, а в Убунте нет. И что с ней делать? С собой таскать мутрно, дистрибутивщиков замучаешься уговаривать библиотеку включить, да и если уговоришь, то включат тольно в следующей версии дистрибутива. Поэтому каждый раз приходится проводить исследования на предмет совместимости с дистрибутивами. LVV>Абсолютно согласен. LVV>Вот надеюсь на С++20.
Профессор, ну Вы серьезно чтоли Подумайте три раза, проанализируйте, для чего же в действительности в языке используется подход header-only .
Безусловно, он, кроме прочего, вполне реализует и ту абстракцию, о которой говорит Pzz — возможность внедрения 3rdparty-решений в свой продукт inplace, чтобы не зависеть от сборочного окружения и не предъявлять к нему требований о наличии этих самых 3rdparty-решений. Но неужели для того чтобы делать inplace, нужен именно header-only? Ведь нет же, и примеров этому предостаточно. В Qt посмотрите паку qtbase/src/3rdparty, в хроме посмотрите chromium/third_party... Да полно примеров, в которых озвученная Pzz проблематика решается не через header-only а более прямыми методами, просто инжектом к себе этих сторонних решений. Либо прям в виде файлов, хоть в дерево продукта как в примерах выше, хоть отдельной папкой типа 3rdsdk. Либо посредством механизмов типа git-submodule. Либо посредством CMake/ExternalProject или подобных методов. Либо еще как, вариантов масса.
Основной же вариант использования header-only подхода заключается в том, чтобы получить возможность более плотно сращивать "свой прикладной" код с "ихним библиотечным", что дает плюсы, недостижимые вне подхода header-only. Эти плюсы бывают примерно такие:
1. возможность эксплуатировать generic-решения, сращивать их со своей прикладухой более эффективно (обычно на порядки) по сравнению с использованием не-generic-решений (сквозь фиксированный API). Для наглядности, сравните использование std::sort и сишный qsort
2. возможность выноса части функционала в compile-time. Для наглядности — static_sort, gcem, давеча тут на форуме обсуждали как константные строки обфускейтить чтобы они в бинаре в открытом виде не светились, а в рантайме их обратно в нормальную форму приводить и использовать (эдакая защита против кул-хацкеров), ... Так же, сюда можно отнести, например, диспетчеризацию функций сериализации подструктур, посмотрите любой плюсовый сериализатор, например вот первый из вашего списка, https://github.com/p-ranav/alpaca/blob/master/samples/demo.cpp#L26. Просто передаем ему сложный объект, и сериализатор сам всю его внутрянку правильно определяет/обрабатывает.
3. возможность оптимизатору строить существенно более эффективный код за счет повсеместного инлайнинга
Собственно, ради вот этих вот барышей и делают header-only. А "подружиться с дистрибутивом" — это просто побочный эффект, мелочь, не более.
V>Собственно, ради вот этих вот барышей и делают header-only. А "подружиться с дистрибутивом" — это просто побочный эффект, мелочь, не более.
Что мешает сделать то же самое на модулях ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
V>>Собственно, ради вот этих вот барышей и делают header-only. А "подружиться с дистрибутивом" — это просто побочный эффект, мелочь, не более. LVV>Что мешает сделать то же самое на модулях ?
Тот прискорбный факт, что пока модули полноценно присутствуют только в стандарте, поддержка в компиляторах все еще на экспериментальном уровне и доступна не только лишь всем (огромное количество проектов все еще на C++17, а многие еще на C++14 и C++11).
Здравствуйте, LaptevVV, Вы писали:
V>>Собственно, ради вот этих вот барышей и делают header-only. А "подружиться с дистрибутивом" — это просто побочный эффект, мелочь, не более. LVV>Что мешает сделать то же самое на модулях ?
Да ничего не мешает, можно и на модулях конечно . Модули20 это не контерпарт header-only, это ортогональный к header-only инструмент. Его можно считать заменой для "исторического сишного механизма модульности". И если взять какую ни будь header-only библиотеку и портировать ее с легаси-модульности (на основе #include) на Модули20, то, кроме формы, ничего не изменится. Было — кучка файлов .hpp без .cpp/lib, стало — один файл .ixx без .cxx (или .cppm или какое там расширение будет и реализационной части Модуля20). Было — плюсовые исходники с шаблонами и прочей мутью, стало — это же все прекомпилированное в некое промежуточное представление. Прикладнику все так же нужно истанцировать те же самые библиотечные шаблоны что и раньше, вызывать/использовать все те же inline/constexpr сущности, то есть, кроме формы представления библиотеки ничего не меняется. Все проблемы о которых говорил Pzz — они в случае с Модулями20 все так же имеют место, дистрибутив все так же должен обеспечивать наличие нужных модулей во время сборки (или таскай их с собой как и в случае легаси-модульности), все так же должен обеспечивать правильные .so/dll в рантайме (или инсталируй их вместе со своим приложением), то есть, проблема "подружиться с дистрибутивом" никуда не уходит.
Основная разница между Модулями20 и "историческим сишным механизмом модульности" только в форме прекомпилированных библиотек:
модульность
dynamic-lib
static-lib
header-only
легаси
пачка файлов .hpp + .so/dll
пачка файлов .hpp + .lib
пачка файлов .hpp
Модули20
файл .ixx + .so
файл .ixx + .cxx
файл .ixx
Еще есть небольшая разница в контроле управляющих препроцессорных конструкций и режимов компиляции, с Модулями20 чуть сложнее в этом накосячить.
Другими словами, если header-only исполнить на Модулях20, то они не перестанут быть header-only
Здравствуйте, vopl, Вы писали:
V>Другими словами, если header-only исполнить на Модулях20, то они не перестанут быть header-only
Все-таки есть надежна, что на модулях библиотеки на одних шаблонах будут несколько эффективнее, чем нонешние header-only, т.к. в случае с модулями компилятор может сохранять промежуточное представление уже однажды скомпилированного модуля. Что позволит избежать перекомпиляции одних и тех же заголовков в каждом из TU, подключающем библиотеку.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, vopl, Вы писали:
V>>Другими словами, если header-only исполнить на Модулях20, то они не перестанут быть header-only
S>Все-таки есть надежна, что на модулях библиотеки на одних шаблонах будут несколько эффективнее, чем нонешние header-only, т.к. в случае с модулями компилятор может сохранять промежуточное представление уже однажды скомпилированного модуля. Что позволит избежать перекомпиляции одних и тех же заголовков в каждом из TU, подключающем библиотеку.
Вот, кстати, в эту сторону — есть серьезные опасения что в плане скорости компиляции сильно-шаблонного кода особых подвижек не случится, по крайней мере в g++. Исхожу из тех соображений. что основная тяжесть, которая тормозит компиляцию — это воплощение шаблонов и дальнейшая кодогенерация/оптимизация, а вовсе не парсинг сотен мегабайт файлов заголовков, в чем можно убедиться уже сейчас если одновременно
1. задействовать тяжелый шаблонный код (например, какой ни будь более менее массивный парсер над какой ни будь нетривиальной грамматикой силами boost::spirit)
2. задействовать механизм прекомпилированных заголовков, который делает примерно то что должны делать Модули20 — препарсенные/прекомпилированные исходники представляет в некоей промежуточной форме, удобной для дальнейшей компиляции (ну и этим pch прекомпилировать boost::spirit и прочий стафф, необходимый прикладному коду воплощения прикладного парсера)
В результате мы получим, с одной стороны — прекомпилированный boost::spirit (наш аналог Модуля20 в сабжевом аспекте), и с другой — по прежнему массивное использование его шаблонных сущностей на прикладной стороне. Практика показывает, что в такой схеме применение прекомпиляции не ускоряет компиляцию сильно-шаблонного прикладного кода, а зачастую даже наоборот, замедляет ее за счет того что промежуточное представление прекомпилированных заголовков имеет большой размер, и требуется много времени для того чтобы его поднимать с диска при компиляции каждой единицы трансляции, импортирующей наш Модуль20. А стадия воплощения библиотечных шаблонов и дальнейшая кодогенерация/оптимизация — как были тяжелыми до Модулей20, так и останутся такими же тяжелыми при них.
Здравствуйте, vopl, Вы писали:
V>Вот, кстати, в эту сторону — есть серьезные опасения что в плане скорости компиляции сильно-шаблонного кода особых подвижек не случится, по крайней мере в g++. Исхожу из тех соображений. что основная тяжесть, которая тормозит компиляцию — это воплощение шаблонов и дальнейшая кодогенерация/оптимизация, а вовсе не парсинг сотен мегабайт файлов заголовков, в чем можно убедиться уже сейчас
У меня это подозрение уже лет 6 или 7 как. Помнится, еще до принятия стандарта C++20 делал замеры для g++ и clang++ с их флажками, которые включали вывод статистики о времени, затраченном при компиляции одного из проектов. Точных цифр уже не помню, но было что-то вроде парсинг исходников -- 2s, инстанциирование шаблонов -- 6s, оптимизация кода -- 6s. Т.е. затраты на парсинг были в разы меньше, чем на все остальные стадии компиляции.
Собственно, это одна из главных причин моего, скажем мягко, скептического отношения к введению модулей в C++.
Но, вроде как в Интернетах пишут, что для каких-то проектов переход на модули таки дал заметный прирост скорости компиляции.
Правда, в тех же Интернетах другие пишут, что стало даже хуже, т.к. ухудшилось распараллеливание сборки.
Подумайте три раза, проанализируйте, для чего же в действительности в языке используется подход header-only 
.
. Модули20 это не контерпарт header-only, это ортогональный к header-only инструмент. Его можно считать заменой для "исторического сишного механизма модульности". И если взять какую ни будь header-only библиотеку и портировать ее с легаси-модульности (на основе #include) на Модули20, то, кроме формы, ничего не изменится. Было — кучка файлов .hpp без .cpp/lib, стало — один файл .ixx без .cxx (или .cppm или какое там расширение будет и реализационной части Модуля20). Было — плюсовые исходники с шаблонами и прочей мутью, стало — это же все прекомпилированное в некое промежуточное представление. Прикладнику все так же нужно истанцировать те же самые библиотечные шаблоны что и раньше, вызывать/использовать все те же inline/constexpr сущности, то есть, кроме формы представления библиотеки ничего не меняется. Все проблемы о которых говорил Pzz — они в случае с Модулями20 все так же имеют место, дистрибутив все так же должен обеспечивать наличие нужных модулей во время сборки (или таскай их с собой как и в случае легаси-модульности), все так же должен обеспечивать правильные .so/dll в рантайме (или инсталируй их вместе со своим приложением), то есть, проблема "подружиться с дистрибутивом" никуда не уходит.