c++ parsing
olololololololo
На clang не смотрел? Они уже очень многое компилируют.
Мы пробовали elsa несколько лет назад, и она с каждым обновлением gcc теряла способность парсить его хедеры (STL тот же). Абсолютно с каждым. Имхо, с++ - это такой пиздец, что его может парсить только что-то очень активно разрабатываемое, на мертвые и полумертвые проекты можно даже не смотреть.
Мы пробовали elsa несколько лет назад, и она с каждым обновлением gcc теряла способность парсить его хедеры (STL тот же). Абсолютно с каждым. Имхо, с++ - это такой пиздец, что его может парсить только что-то очень активно разрабатываемое, на мертвые и полумертвые проекты можно даже не смотреть.
нет, не смотрел - посмотрю, спасибо.
именно такую обстановку я и заметил - gcc слишком быстро вперёд уходит. разумнее его внутренности и брать.
именно такую обстановку я и заметил - gcc слишком быстро вперёд уходит. разумнее его внутренности и брать.
Причем они очень забавные в этом своем FSF.
Нежелание делиться интерналами они объясняют нежеланием принимать чужие патчи.
Это как отказываться лечить зубы, потому что на улице Клубова переезд закрыт.
Нежелание делиться интерналами они объясняют нежеланием принимать чужие патчи.
Это как отказываться лечить зубы, потому что на улице Клубова переезд закрыт.
Нежелание делиться интерналами они объясняют нежеланием принимать чужие патчи.Это где такое?
Я когда-то читал их официальный флейм, там основная идея была что если писать простой и понятный код, то Корпорации мгновенно напишут проприетарные плагины к gcc, на которые пользователи польстятся и потеряют Свободу. Этого, конечно, допустить нельзя, лучше пусть неких программ не существует вовсе чем они будут проприетарными. Поэтому внутренности gcc должны быть как можно более кривыми и непонятными, совершенно недокументированными и меняющимися без предупреждения.
Я совершенно не преувеличиваю между прочим, gcc-devel абсолютно безумен даже по меркам FSF. Надеюсь, что скоро они сдохнут второй и последний раз.
Сейчас они с этим поборолись при помощи Новой и Улучшенной GPLv3 + gcc exception. Суть токова: твоей программе как бы надобно линковаться с gcc runtime же, которая под GPL, но они дают тебе право лицензировать твою программу как угодно, если она была получена в результате Eligible Compilation Process, который включает в себя использование гцц только с православными плагинами.
Впрочем, кажется, для задач например парсинга, которые не кончаются генерацией кода, гцц можно использовать (ну, если успели исправить своё говно за последние два года).
генератор парсеров для с++ такой, чтобы сесть и переписать формальную грамматику в грамматику генератора ты не найдешь, там много заморочек даже для "стандартного" с++, а уж для всех диалектов и c++0x подавно. если надо для себя - поддерживаю идею про clang (llvm если для компании, можно купить, они поддерживают кучу диалектов.
обсуждение на stackoverflow
если действительно хочешь сам заебаться
, то лучше сразу брать удобный код-генератор - ANTLR мой фаворит в данном случае.
к слову у нас парсер на bison написан, но так исторически сложилось, это не удобно.
обсуждение на stackoverflow
если действительно хочешь сам заебаться
, то лучше сразу брать удобный код-генератор - ANTLR мой фаворит в данном случае.к слову у нас парсер на bison написан, но так исторически сложилось, это не удобно.
к сожалению, моя компания не может столько себе позволить
between $40,000 and $250,000.
Это где такое?Может быть, так было раньше (пруфлинк? но за последние 6 лет ничего подобного в рассылке я не читал, на gcc summit тоже не слышал. Думаю, значительная часть политических стонов по поводу gcc просто связана с тем, что gcc есть флагманский проект FSF, и уж точно самый успешный. Поэтому у Столлмана насчет него не совсем здоровая реакция. При этом ключевых разработчиков это давно задрало, и на данный момент любой выпендреж со стороны FSF легко приведет к форку. Из последнего интересующиеся могут нагуглить флейм по поводу GPL vs GFDL.
Я когда-то читал их официальный флейм, там основная идея была что если писать простой и понятный код, то Корпорации мгновенно напишут проприетарные плагины к gcc, на которые пользователи польстятся и потеряют Свободу. Этого, конечно, допустить нельзя, лучше пусть неких программ не существует вовсе чем они будут проприетарными. Поэтому внутренности gcc должны быть как можно более кривыми и непонятными, совершенно недокументированными и меняющимися без предупреждения.
Нежелания делиться интерналами, опять же, за последние 6 лет не было (пруфлинк?). Причем непонятно, какое может быть нежелание для проекта с открытыми исходниками?
совершенно не преувеличиваю между прочим, gcc-devel абсолютно безумен даже по меркам FSF. Надеюсь, что скоро они сдохнут второй и последний раз.
Это хуйня, уж извини. Не дождешься.
ейчас они с этим поборолись при помощи Новой и Улучшенной GPLv3 + gcc exception. Суть токова: твоей программе как бы надобно линковаться с gcc runtime же, которая под GPL, но они дают тебе право лицензировать твою программу как угодно, если она была получена в результате Eligible Compilation Process, который включает в себя использование гцц только с православными плагинами.
Это правда. Тем не менее, плагины сами по себе для разработчика ничего не дают. Это просто набор колбэков из определенных мест компилятора. Писать плагин ничем не легче, чем просто взять gcc и исправить так, как нужно. Разработчики плагинами не очень заинтересованы, так как из двух точек зрения - что плагины привлекают новых людей и что эти люди для пользы самого gcc ничего не дают - преобладает вторая. Поэтому никто не парится вещами вроде сохранения API, есть более интересные дела.
Что касается парсинга, то C++ парсер в gcc сложный, и если clang с плюсами пробился, то с ним будет работать наверняка удобнее.
Извини за мат вчера, не выдержал.
Эта страница как раз пример не совсем здоровой реакции FSF, да. На ней есть ссылки на обсуждения, где есть примеры того, как кто-то когда-то пытался использовать gcc в проприетарных компиляторах, и как этого боится Столлман. Но, как я уже написал, это не есть мнение активных на данный момент разработчиков. Их мнение в том, что плагины ничего особо не облегчают, сложность разработки связана со сложностью компиляторных алгоритмов вообще, но дают бонус вроде использования инсталлированного компилятора. Поэтому почему бы не добавить набор хуков, по которым можно в принципе делать все то, что нужно просящим это людям (Mozilla, MILEPOST и т.п. плюс инсталлировать необходимый набор хедеров. Это все уже есть. Новые хуки добавляют, если есть реальный пример необходимости в них, гипотетический не катит. А стабильность API не гарантируют, во-первых, потому, что возникающий maintenance burden не окупается бонусами от нее, то есть люди, пишущие плагины, не приносят интересные части кода обратно. (Есть сложности для новичков, хотящих подать патч, как технические, так и юридические, но это отдельная тема.) А во-вторых, в компиляторе это непросто гарантировать вообще. Но никто специально API ломать не будет, само собой. Поэтому внутренности gcc должны быть как можно более кривыми и непонятными - это мальца перебор. За последние лет пять они стали как раз сильно более прямыми и понятными.
Кстати, GCC Wiki не есть официальный флейм, ее может редактировать кто угодно. В частности, эту страницу ни один из активных разработчиков не писал. Но взгляд со стороны пользователя 2008 года давности (когда официальных плагинов еще не было) она дает. Я постарался показать ситуацию с другой стороны.
Эта страница как раз пример не совсем здоровой реакции FSF, да. На ней есть ссылки на обсуждения, где есть примеры того, как кто-то когда-то пытался использовать gcc в проприетарных компиляторах, и как этого боится Столлман. Но, как я уже написал, это не есть мнение активных на данный момент разработчиков. Их мнение в том, что плагины ничего особо не облегчают, сложность разработки связана со сложностью компиляторных алгоритмов вообще, но дают бонус вроде использования инсталлированного компилятора. Поэтому почему бы не добавить набор хуков, по которым можно в принципе делать все то, что нужно просящим это людям (Mozilla, MILEPOST и т.п. плюс инсталлировать необходимый набор хедеров. Это все уже есть. Новые хуки добавляют, если есть реальный пример необходимости в них, гипотетический не катит. А стабильность API не гарантируют, во-первых, потому, что возникающий maintenance burden не окупается бонусами от нее, то есть люди, пишущие плагины, не приносят интересные части кода обратно. (Есть сложности для новичков, хотящих подать патч, как технические, так и юридические, но это отдельная тема.) А во-вторых, в компиляторе это непросто гарантировать вообще. Но никто специально API ломать не будет, само собой. Поэтому внутренности gcc должны быть как можно более кривыми и непонятными - это мальца перебор. За последние лет пять они стали как раз сильно более прямыми и понятными.
Кстати, GCC Wiki не есть официальный флейм, ее может редактировать кто угодно. В частности, эту страницу ни один из активных разработчиков не писал. Но взгляд со стороны пользователя 2008 года давности (когда официальных плагинов еще не было) она дает. Я постарался показать ситуацию с другой стороны.
Оставить комментарий
yolki
Какие есть на сегодняшний день парсеры (или генераторы парсеров способные обработать С++ "in the wild" ? ну например firefox или Qt.я в конец разуверился в способности себя написать такой после прочтения вот этого.
упоминающийся генератор elkhound и elsa похоже далеко out-of-date (как минимум, лет на 5). "с ходу" собрать их на коленке не получилось, нужно ковырять исходники. может займусь этим, если не найду более подходящих решений.
я попытался заглянуть в исходники gcc. в части, касающиеся внутреннего/промежуточного представления (intermidiate representation обнаружил любопытное отношение к этому делу.
внутренности скрываются! любопытный тред вот тут
чесслово, не ожидал такого отношения в опенсорсной коммьюнити.
может, так обстояли дела 7 лет назад и после мержа tree-ssa в mainstream всё в шоколаде?
насколько юзабельны сейчас -fdump-tree... ?