Boost 1.82

Вообще, Boost.Spirit генерит хорошие по качеству парсеры. Но сейчас я бы использовал ANTLR.

Если речь идёт о более серьёзных вещах, чем разбор HTML/JSON/INI (для которых и так есть готовые тулзы), то уж лучше вручную костылять на 99-ой Сишечке, чем потом страдая пытаться избавиться от всех недостатков готового комбайна, тем более написанного на Джаве.

Но сейчас я бы использовал ANTLR.

А я бы PEGTL или lexy.

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

fmt же, говорят, в стандарт затащили (ну, точнее, сделали стандарт на основе fmt).

Ну да, это как раз std::format. Только вот проблема, что единственная доступная для линукса сейчас реализация std::format - это всё тот же fmtlib, а ни в libstdc++, ни в libc++ своё ещё не завезли. В msvc вроде что-то сделали, но я не проверял.

Так что я пока по-прежнему fmtlib тащу и не парюсь.

ни в libstdc++, ни в libc++ своё ещё не завезли

Завезли в gcc-13 и в Libc++ 16.

Собственно, главной моей претензией к Спириту является (являлся) степенной рост сложности инстанциируемого кода при росте сложности грамматики. Работает, спору нет, быстро, но компиляется века́ми.

У PEGTL подход /внешне схожий/. И как оно, не ставит канпелятор колом?

Ставит. :)

Поэтому https://lexy.foonathan.net мне больше нравится.

Вы, видимо, не в теме про генераторы парсеров.

Чо-т я боюсь представить себе, как будет выглядеть сколько-нибудь сложная грамматика при таком подходе.

Дополню, что обе используют алгоритм Ryu, а не Dragonbox, как в fmtlib.

Вообще, Boost.Spirit генерит хорошие по качеству парсеры.

Которые медленные не только по скорости компиляции, но и даже по выполнению?

Да сам пока экспериментирую. :)

Мне в lexy нравятся парсеры различных классов и свойств юникодных символов, тогда как в PEGTL для этого используется ICU.

Вы, видимо, не в теме про генераторы парсеров.

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

Не знаю, кто такие сложные проекты, но если конечные автоматы порождают у кого-то попоболь, может быть, ему/ей/им стоит больше времени проводить на воздухе, в движении, а не в офисе?

На моих тестах (пятнадцатилетней давности) работало как из пушки.

Из опубликованного прямо сейчас могу вспомнить только статью Алекса Отта

Вообще, конечно, от грамматики, и того, как она описана, зависит многое. Так что, YMMV

До кучи: для Си недавно нашёл чудный https://github.com/ianh/owl.

На мой взгляд, его грамматика проще, чем в Bison/Flex.

Потому что авторы GTK решили разместить на своём сайте документацию не только по GTK но и по другим библиотекам использующим Glib/GObject?

Может это потому, что все эти проекты разрабатываются «GTK Development Team»?

И что дальше?

Подпроекты и всё такое

Продолжай мысль.

компиляется века́ми

Вторая версия поди? X3 сильно быстрее, за годы может справиться.

Правда, оно из experimental никак не выходит, и видимо уже не выйдет.

В boost/math просто так затребовали C++14: https://github.com/boostorg/math/pull/905

Наверное в последующих патчах возможно как-то и заиспользовали или будут использовать возможности С++14, но затребовали просто так, а не во время реализации/рефакторинга чего-то…

Да, ещё вспомнил lexertl и parsertl от Бена Хансона. Там правила можно в рантайме добавлять.

А ещё у него есть основанный на них gram_grep.

https://www.codeproject.com/Articles/1197135/gram-grep-grep-for-the-21st-Century

нормальные посоны не пишут итераторы рингбуфера - потому что это противоречит его семантике. в рингбуфер можно только положить и только взять.

И снова не удержался.

Ваша безапелляционность меня просто умиляет.

Вот есть у меня процессик где эти ring buffers плодятся десятками и сотнями тысяч (от instance зависит). Для каждого имею оценку сверху по размеру. НО, преаллоцировать всё это дело «сильно дорого». Там где их сильно много - подавляющее большинство «полупустые».

Вопрос - а напархуа?

И здесь мы приходим к тому что ring buffers иногда надо resize…

Дальше больше - business logic такова что нужно часто бегать по предыдущеми entries, т.е. доступа к head and tail - не хватает.

К чему я вот всё это - да идите вы в Ж со своими упрощениями…

Вы там вякали про circular_buffer: покажите таки ваш. Я так понимаю люди пишущие boost вам в подмётки не годятся.