> Присоединяюсь к вопросу. С binpac работать приходилось, отличная штука, которая может и
> файлы и поток парсить. Какие части декларативно никак не сделать (редко,
> но бывает) - можно вручную попарсить, есть встроенные в binpac средства
> для связи с ручным парсером. А если внутри того, что парсишь
> вручную снова можно декларативно парсить - тоже не проблема, легко и
> обратно к декларативному парсингу вернуться А вот это хороший вопрос :) В целом, да, проекты весьма похожие. Если смотреть на самый верхний уровень, то:
1. binpac на самом деле как бы мертв. Сейчас из этого семейства жив, как подсказали, binpac++ AKA Spicy — http://www.icir.org/hilti/
2. binpac таргетируется ровно на один язык — на C++.
3. Spicy таргетируется даже не на язык, а на промежуточный код платформы clang, соответственно, в теории сможет поддерживать все языки, поддерживаемые clang — но на практике это сейчас и в обозримом будущем, насколько я понимаю, это C / C++ / Objective C / Swift.
4. Все выражения binpac/Spicy — это по сути просто выражения на C / C++ — со всеми плюсами и минусами. Т.е. можно делать что угодно, но из-за этого за рамки C++ без радикальной переделки языка не выйдешь.
5. В binpac все относительно плохо с верификацией, формальной спецификацией и покрытием тестами (де факто ее/его нет). В Spicy — все сильно лучше, но там сам проект пока скорее на стадии ранней альфы.
6. Язык в KS — YAML специального вида, язык в binpac/Spicy — текстовый, C-подобный.
Если спуститься ниже, на технический уровень, то:
1. Разумеется, есть ряд концептуальных отличий в применяемых подходах. Например, в KS есть концепция процессинга буферов — можно сказать, что вот здесь внутри этого массива байтов — поток, соответствующий zlib-сжатию. В binpac, насколько я понимаю, все такие вещи делаются исключительно внешними средствами — буфер надо экспортировать в C, позвать zlib, передать обратно вручную.
2. binpac на сейчас, разумеется, гораздо более mature; в KS пока нет, скажем, толком bitfields (но скоро будут), весьма ограниченные аналоги bitpac'овского &check, нет никаких ручек для performance fine-tuning типа bitpac'овского &chunked и т.д. Большей частью это связано с тем, что не хочется гнаться за специализированными фичами, а обеспечить их более-менее хорошую реализацию для всех поддерживаемых языков.
