В бусте много где надо внимательно читать документацию

Ни метапрограммирование ни обычное сами по себе обычно не вызывают проблем. Но spirit живет на стыке и не очень хорошо документирован.

ну boost::optional имеет get_value_or, на который наступил практический каждый первый, передав туда что-то временное

а boost::variant реализован черз такой фигурный костыль, что для большого числа аргументов требует пяток макросов до инклюда бустовых хедеров задефайнить

С этим встречаешься достаточно рано в изучении С++ и быстро привыкаешь следить.

Это не идет ни в какое сравнение с кодом, который сгенерирует spirit на граматике среднего размера. При этом по всем канонам жанра автор уволился за пару лет до моего прихода в компанию.

Это нерешаемая проблема спирита или надо быть внимательнее? А то я как раз к нему присматривался

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

Можно ли на уровне типов защититься от неправильного использования ссылок в парсерах? Не знаю. Не уверен.

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

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

Я хотел сразу с 3 начинать. Она +- стабильная, но у меня и код не в продакшен

Ну а в целом он мне даже понравился, но ошибка может дорого стоить.

Еще слышал, что на больших граматиках спирит положит компилятор. Опять же может быть в новой версии с этим что-то сделали.

Я тоже слышал такое, решали явным инстанцированием

У меня такого размаха пока не планируется

Коллеги, кто из Нижнего Новгорода, хочу пригласить вас на Митап по C++, который пройдет 21 марта. Все подробности здесь. Будут вопросы, обращайтесь.
https://t.me/ProCxxNews/141

Запись будет?

Сейчас думаю над этим моментом, ищу варианты.

Всем привет! Столкнулся со следующей проблемой. У меня есть сервер, который принимает запросы, протокол не важен. Тест кейс такой:
1. Формирую большой запрос, для которого у сервиса хватит памяти чтобы обработать, получаю валидный результат.
2. Формирую большой запрос, для которого у сервиса точно не хватит памяти, чтобы обработать - получаю bad allocation
3. Снова формирую такой же запрос, как и на первом шаге - получаю bad allocation
4. Формирую большой запрос, но меньше чем в первом шаге - получаю валидный ответ.
5. До перезапуска сервиса, все запросы, такого же размера, как в первом шаге возвращают bad allocation.

В связи с этим, несколько вопросов:
1. Возможно ли такое поведение из-за выделения памяти ОС? После bad allocation что-то случается с фрагментацией памяти, и я не могу уже выделять такие большие области как прежде?
2. Поведение замечено на WIndows. Есть ли какие то особенности для этой ОС с хэндлом bad allocation исключения?

Спасибо за внимание!

Мемори ликов нет?

может память утекла, когда неожиданно exception вылетел?

нет, видно по диспетчеру задач, что память возвращается ОС

ну диспетчер - не показатель, там может утечь пару байтиков, и все