Здравствуйте, vdimas, Вы писали:
_>>Перегрузка операторов в C? А ты как всегда шедеврален... )))
V>Релэкс, я знал, что тебе нечего будет возразить, кроме этого.
V>Но я ж специально проверил, что "в стиле C" написано в кавычках.
V>Т.е. не требовалось на С, требовалось в духе, ОК.
О, пошли отмазки. )))
V>Вот такая инициализация глобальных правил, по которым могут работать несколько экземпляров парсера — это очень даже в духе С.
V>С точностью до перегрузки операторов, ес-но.
V>Без этой перегрузки было бы что-то вроде:
V>V>Rule * A = ruleOr(B, ruleOr(ruleCat(A, C), ruleCat(ruleCat(A, B), C);
V>То бишь, задание AST этого БНФ-выражения... Тоже вполне работоспособно, но лучше не стоит так упарываться. ))
Даже если забыть про дикую уродливость подобного решения... Ты действительно считаешь, что данный код скомпилируется в те же инструкции, что и изначальный пример? )))
_>>А в C у нас имеется только последний вариант, так что точного аналога Spirit'a просто не существует. Именно в этом был мой тезис, который очевиден каждому вменяемому читателю. )))
V>Каждому вменяемому читателю видна насосанность из пальца вот этого требования аналога Spirit под С. Мало того, что о такой постановке вопроса речи даже не было (!!!), дык, по современным меркам пытаться гнуть в эту сторону — это заведомо сливать любой спор, бо ограничений на распространённость С++ давно уже нет.
Хех, вообще то именно об этом я тут и писал. Что Spirit является максимально плохим примером для нашей дискуссии (она же вообще то не про парсеры, а про стили) и надо взять любой (ну почти — надо чтобы он всё же был реализуем на C) другой пример современного шаблонного кода на C++ и тогда уже обсуждать. Так что похоже ты тут споришь с какими-то голосами в своей голове. )))
Здравствуйте, alex_public, Вы писали:
_>>>Перегрузка операторов в C? А ты как всегда шедеврален... )))
V>>Релэкс, я знал, что тебе нечего будет возразить, кроме этого.
V>>Но я ж специально проверил, что "в стиле C" написано в кавычках.
V>>Т.е. не требовалось на С, требовалось в духе, ОК.
_>О, пошли отмазки. )))
Ожидаемо скатился в троллизм.
Твои слова?
Так вот написать его полноценный аналог "в стиле C" просто невозможно
Здравствуйте, alex_public, Вы писали:
_>Ну т.е. если перевести с твоего языка на русский, то будет: "не могу". )))
В переводе на русский будет — "у alex_public в Киеве дядька".
Напомню твой залёт:
- Если есть желание продемонстрировать честный аналог Spirit'a в стиле C, то надо взять исходники Bison + Flex.
Spirit — это фреймворк для построения
комбинаторного парсера. Напротив, семейство yacc (и его многочисленные клоны, включая бизона, бизона++ и прочих буфалло) — это полноценные
LALR(1),
LR(1), местами
LR(k) и даже
GLR-парсеры.
Похоже, эти перечисленные абревиатуры являются для тебя натуральной китайской грамотой, коль ты умудряешься давать советы, типа таких:
Если бы в моём проект стоял выбор между использованием Bison + Flex и Spirit, то скорее всего я бы предпочёл последнее, в силу более удобного API
Т.е., даже не глядя на вид грамматики, ты уже сделал выбор по некоему мифическому АПИ.
Откуда ты знаешь, какой АПИ у того же Bison++? Да у него чудесный С++ АПИ.
Мало того, АПИ Spirit просто ужасно, коряво, неюзабельно и сугубо write-only. Оно ужасно именно из-за тех вещей, что EDSL в С++ не всегда выходит гладко, особенно в деле ДЕКЛАРАТИВНОГО описания грамматик для парсинга с попыток связать эту декларацию с колбэками (semantic actions). Не они первые и не они последние, насчет EDSL парсеров в С++. Это болезнь роста как специалиста C++, многие через неё проходят.
Далее вообще смешно:
- Можешь предложить более близкий аналог Spirit'a из мира C? )
Тут сначала упал со стула, затем поднялся и внятно тебе ответил:
Слава богу, редко кому в голову приходила идея реализовывать комбинаторные парсеры на С. Комбинаторные парсеры — это изобретение далёких от программирования людей, которые пользовали в ежедневной практике функциональные языки. Они не знали теорию грамматик и писали парсеры "в лоб", получая естественные тормоза и жор памяти.
Похоже, ты не понял ответа моего и так не слишком завуалированного ответа, поэтому, перевожу на совсем прямую речь:
— комбинаторные парсеры предназначены для
случайных в отрасли людей;
— случайные в отрасли люди редко пишут на С (как минимум редко пишут генераторы парсеров на С, ы-ы-ы).
Тем не менее, реализаций парсеров семейства PEG на С существует
более одной. Сие означает, что я-то как раз "могу" (могу привести примеры), но считаю их эээ... малость "неприличными" для приличного общества. Потому что упоминание PEG всуе, это как выйти на Красную площадь и ругаться матом. Судя по твоему ответу, ты не в курсе всех этих тонкостей, но опять и снова поторопился выступить в роли тролля. )) ИМХО, тролль должен хорошо разбираться в предмете, иначе это не тролль, а так, неудачная мимикрия из разряда "обалажался — притворись троллем".
Одно меня радует в приведенных ссылках на комбинаторные парсеры на С (который peg/leg), что после многолетней упорной смены версий и роста их аж до 0.1.18 (т.е. даже не альфы), авторы, судя по всему, одумались. Ну, мож, прочитали пару книг, наконец...
Чего и всем советую.
Здравствуйте, vdimas, Вы писали:
_>>>>Перегрузка операторов в C? А ты как всегда шедеврален... )))
V>>>Релэкс, я знал, что тебе нечего будет возразить, кроме этого.
V>>>Но я ж специально проверил, что "в стиле C" написано в кавычках.
V>>>Т.е. не требовалось на С, требовалось в духе, ОК.
_>>О, пошли отмазки. )))
V>Ожидаемо скатился в троллизм.
V>Твои слова?
V>V>Так вот написать его полноценный аналог "в стиле C" просто невозможно
Ну т.е. перегрузка операторов — это по твоему код "в стиле C", да?
Здравствуйте, vdimas, Вы писали:
_>>Ну т.е. если перевести с твоего языка на русский, то будет: "не могу". )))
V>V>- Можешь предложить более близкий аналог Spirit'a из мира C? )
V>Тут сначала упал со стула, затем поднялся и внятно тебе ответил:
V>V>Слава богу, редко кому в голову приходила идея реализовывать комбинаторные парсеры на С. Комбинаторные парсеры — это изобретение далёких от программирования людей, которые пользовали в ежедневной практике функциональные языки. Они не знали теорию грамматик и писали парсеры "в лоб", получая естественные тормоза и жор памяти.
V>Похоже, ты не понял ответа моего и так не слишком завуалированного ответа, поэтому, перевожу на совсем прямую речь:
V>- комбинаторные парсеры предназначены для случайных в отрасли людей;
V>- случайные в отрасли люди редко пишут на С (как минимум редко пишут генераторы парсеров на С, ы-ы-ы).
V>Тем не менее, реализаций парсеров семейства PEG на С существует более одной. Сие означает, что я-то как раз "могу" (могу привести примеры), но считаю их эээ... малость "неприличными" для приличного общества. Потому что упоминание PEG всуе, это как выйти на Красную площадь и ругаться матом. Судя по твоему ответу, ты не в курсе всех этих тонкостей, но опять и снова поторопился выступить в роли тролля. )) ИМХО, тролль должен хорошо разбираться в предмете, иначе это не тролль, а так, неудачная мимикрия из разряда "обалажался — притворись троллем".
Молодец, домашнее задание по владению гуглом ты выполнил. Но понимания фундаментальных архитектурных принципов у тебя по прежнему нет, так что пока зачёта не предвидится.
Показанные тобой примеры парсеров при всей алгоритмической похожести не имеют ничего общего со Spirit'ом с точки зрения архитектуры. Они все представляю собой просто обычный парсер с кастомизируемым форматом. Он однажды собирается в приложение и потом его поведение настраивается внешними рантайм данными (строкой с грамматикой). В противоположность этому Spirit (так же как и Bison+Flex) генерирует под каждую грамматику разный код, который потом активно оптимизируется (включая глубокий инлайн) компилятором. Именно этим и обусловлена высокая эффективность всех парсеров на базе кодогенераторов. А уникальность Spirit'а заключается только в том, что это EDSL генератор, а не внешний.
Да, кстати, могу тебе сделать подсказку для дальнейших попыток найти более адекватный аналог на C (и тем самым показать что твоя придирка не была глупой). По идее единственным способом написать аналог Spirit'а на C будет построение некого страшного монстра на макросах. Сомневаюсь, что кто-то подобное делал, но если нет такого решения, то скорее всего нет и никакого другого.
