LINUX.ORG.RU

Нужны ли компиляторам универсальные парсеры?

 , ,


3

5

Доброй пятницы, ЛОР.

Вопрос в первую очередь тем, кто погружался в исходники компиляторов: gcc, clang, rustc, fpc, go… Используют ли они универсальные инструменты для лексического анализа и разбора — все эти flex, bison и др., которые рекомендуют учебники?

Или же там для разбора исходников написано что-то своё, более низкоуровневое?

И второй вопрос — что посоветуете человеку, который хочет что-то вытаскивать из написанного людьми (*) кода на C или C++? Пойти по классике и упороться flex-ом или?..

В первую очередь интересен первый вопрос, особенно в части gcc и clang. Жду рассказов людей, которые туда погружались и выплыли. :)

(*) - так-то понятно, что можно повесить вывеску «принимается только код, обработанный бьютифаером» и по-бырому сделать «парсер» на регулярках, а то и вручную. И «для себя» и даже для небольшого коллектива это будет вполне нормальное инженерное решение, даже в чём-то юниксвейное. А вот если задаться целью сделать как следует…

Upd: в обсуждении выяснилось, что со вторым вопросом, если не лезть внутрь функций, помогает CastXML. Пример:

castxml globals.cpp --castxml-gccxml -o ./out.xml -I ../core -I /usr/include/qt4

Upd2: gcc-xml, предшественник CastXML, тоже поддерживает ключ -I, но в имевшемся у меня мане он не описан. Выходной файл в этом случае задаётся ключом -fxml=...

Всем спасибо за помощь.

★★★★★

Последнее исправление: hobbit (всего исправлений: 4)
Ответ на: комментарий от anonymous

например это для v4, для antlr3 и это

Не понял что вы хотели сказать. Это всё кошмарные и/или заброшенные, т.е. unusable бэкенды.

И все 100500 готовых грамматик для ANTLR = Неуловимый Джо. Конечно хорошо и удобно, что вы можете взять их готовые и нагенерировать говно-парсеров. Но для получения чего-либо полезного нужно сделать в 100 раз больше, чем описание грамматики. Т.е. это «готовое» подходит чтобы «совсем по-быстрому потыкать палочкой» на жабе, а при игре по-серьезному и/или в долгую начинает мешать (внезапно даже graal не использует antlr).

На всякий переформулирую:

  • для подавляющего большинства жаба-проектов ANTLR в самый раз, ибо «всё в одной песочнице» и пофигу на «много букв».
  • для C/C++ использовать ANTLR это как «назло бабушке уши отморозить», ибо есть re2c, lemon, ragel, bison, hyperscan…
Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

В Го свой лексер, парсер, дерево, SST своё и так далее. Никаких регулярок. В общем код там довольно простой. Зайди на godoc.org/go/ да посмотри. И, соьственно, мотивация в том, что универсальные инструменты не дают хороших о чётов об ошибках. Ну и так далее.

anonymous
()
Ответ на: комментарий от anonymous

И, соьственно, мотивация в том, что универсальные инструменты не дают хороших о чётов об ошибках.

Вот это, кстати, интересный аргумент. Да, очевидно важный аргумент для компиляторов. И сооответственно совсм не важный для моей задачи, где исходник — данность свыше.

hobbit ★★★★★
() автор топика
Ответ на: комментарий от fsb4000

Все нормальные сайты как минимум двух поточные(sw нужен любому сайту), как максимум задействуют столько ядер CPU сколько нужно им.

А нормальных сайтов в интернете нету. Дальше что?

WASM не нужен, так как не быстрее нормального js

WASM примерно на 30-40% быстрее специально сформированого под оптимизацию JS. Руками такой довольно тяжело писать, так что как минимум нужен трайнспайлер JS->JS.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

потом эти же маркетинговые ходы повторили с Java, продав его как «лучший С++». и C#.

Да, причем, это была как бы замена именно крестам, не Си, чтобы те аутисты, которые освоили C++, но не могут освоить ничего больше, перекатились на жаву. Я очень люблю приводить пример Торвальдса, как человека, который в своей жизни так и не смог освоить ничего, кроме Си и баша - попробуй его убедить писать на паскале.

byko3y ★★★★
()
Ответ на: комментарий от fsb4000

webworker это отдельные системные реальные потоки, там можно делать почти всё что можно делать в обычном js, кроме доступа к DOM, но и в классических GUI тулкитах изменять UI можно лишь из UI потока.

Как бы беда в том, что web worker вообще не может получить доступа к глобальным состояниям. Хоть ДОМ, хоть без ДОМа. А для запросов через fetch не нужны web worker-ы.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

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

Так это и значит «нет». Если б даже не всех, а значительную часть. Вон D как язык во всем (вроде бы) лучше, но что с этим знанием дальше делать.

Ну ты сразу и говори так «мне не предлагают работу на D». Да, есть такое. Зачем это заворачивать в мутные обороты, вроде «индустрии нечего предложить»? Какой индустрии? Где они живет? Как поживают ее родители?

C++ позволял купить компилятор и заменить им компилятор C. И не переписывать свой миллион строк кода (не считая правки мелочей), и не учиться новому языку с нуля, а плавно перетекать на него, в той мере в какой сам захочешь. И это было востребованно. Ни паскаль, ни кто-то другой этого не позволяли.

Паскаль позволяет брать готовый код на Си, собирать его отдельно, пропускать сишные заголовки через автоматический транслятор ( аля https://www.freepascal.org/docs-html/current/user/userse40.html ), и дальше использовать все структуры и функции из модулей на Си, как родные. Родной линкер паскаля умеет линковать объектники Сей в результирующее приложение. И да, совместимость получается примерно как в крестах: из паскаля можно использовать Си, но из Си использовать паскаль довольно затруднительно.

Как я и писал, весь смысл был ни разу не в сохранении возможности использовать код на Си - иначе бы давно уже все перекатились на паскаль. Смысл был в том, чтобы львиная доля мартышек, пишущих на Си, могла и дальше ничему не учиться, а тупо продолжать писать на Си в С++.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

потом эти же маркетинговые ходы повторили с Java, продав его как «лучший С++». и C#

Для многих так оно и было. Для тех, кто на C++ писал медленный и насквозь объектный высокоуровневый код, кто велосипедил управление памятью и интроспекцию. Они перешли на Java и забыли про валидол.

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

byko3y ★★★★
()
Ответ на: комментарий от insw

Не забивай лишним голову, через год другой metaprog выйдет, не прототип, там будет учтен опыт предыдущих поколений.

Отвергнут «опыт предыдущих поколений» 100%.
ИМХНО разработка из серии «слышал звон, но не знает где он».
Впрочем знание это «дело наживное».
Поэтому «прогноз» на то, что в результате будет разработано делать опрометчиво.

Владимир

anonymous
()

У всех более менее распространенных языков - контекстно-зависимая грамматика. Их можно распарсить только либо упоротыми штуками типа GLR-парсеров либо руками с кучей хаков и велосипедов. В 99.99% случаев в компиляторах именно второе. Парсить конкретно плюсы - можешь даже забыть пытаться, это один из самых сложных для разбора языков вообще.

lovesan ★★
()
Ответ на: комментарий от anonymous

Добавочка.

«Знание» может быть представлено в текста или графики.
Проще говоря есть категория знаний для которой лучше подходит тезис «лучше один раз увидеть, чем сто раз услышать».
Что касаемо представления алгоритмов в графическом представлении, то еще никто не знает каким оно должно быть.

Владимир

anonymous
()
Ответ на: комментарий от byko3y

Да, причем, это была как бы замена именно крестам, не Си, чтобы те аутисты, которые освоили C++, но не могут освоить ничего больше, перекатились на жаву.

Не могу удержаться чтобы не поправить знаменитого на LOR-е ыксперда по всему на свете: Java сделали для тех, кто не смог освоить C++.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Что касаемо представления алгоритмов в графическом представлении, то еще никто не знает каким оно должно быть.

К сожалению @metaprog переиначил эту задачу в «разработку визуального Си».

Владимир

anonymous
()
Ответ на: комментарий от anonymous

Что касаемо представления алгоритмов в графическом представлении, то еще никто не знает каким оно должно быть.

Это «вершина айсберга», которой должны предшествовать решения задач:

  • создание архитектуры представления знаний в виде мета данных;
  • создание на ее основе метаданных для разного рода объектов и конечно «знаний»;
  • создание алгоритмов логического вывода на основе мета данных;

А «тяп ляп и в дамки» ИМХНО не профессиональный подход.

Владимир

anonymous
()

Кстати, пока думал о классике, нашёл заметку:

Попробовал я с этими генераторами пожить, но очень быстро запросил пощады. Анализатор, сгенерированный Flex, долго не хотел компилироваться, а под C++ (ни mingw, ни msvc) он у меня так и не скомпилировался. При включенном режиме совместимости с Bison (%option bison-bridge) отказался компилироваться вообще. Flex не знает о существовании Unicode, так что парсить не ASCII на Flex — тот еще изврат. Выданный исходник просто жуткий, многослойный торт из макросов и сплошные глобальные переменные. Хоть и заявляется (вроде как экспериментальная) поддержка C++, но этот вариант у меня тоже не компилировался ни в какую.

Для Ъ: автор сбежал на LEMON, чего и всем желает.

hobbit ★★★★★
() автор топика
Ответ на: комментарий от hobbit

Кстати, пока думал о классике, нашёл заметку: http://blog.mgsxx.com/?p=2643

В ней сказано.

«Анализатор, сгенерированный Flex, долго не хотел компилироваться, а под C++ (ни mingw, ни msvc) он у меня так и не скомпилировался.»

Мамия.
Почему же у меня ушло всего пол дня для того, чтобы перевести flex на C++ и почему он мне исправно служит?

Владимир

anonymous
()
Ответ на: комментарий от eao197

Не могу удержаться чтобы не поправить знаменитого на LOR-е ыксперда по всему на свете: Java сделали для тех, кто не смог освоить C++.

Они и жаву не смогли освоить - отсюда SOLID, GRASP, и прочий мусор. Линус по этому поводу вполне ясно выразился, что на Си стоит писать только для того, чтобы крестомакаки не протекали в твой проект.

byko3y ★★★★
()
Ответ на: комментарий от drsm

Да, JS принципиально однопоточный.

O RLY?

Хорошо, теперь он становится многопоточным. С этими примитивами уже возможно реализовывать произвольный многопоточный алгоритм. Правда, только в FF, хроме, и ноде начиная с 2018 года релиза. Ух и долго же они медлили.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Что касаемо представления алгоритмов в графическом представлении, то еще никто не знает каким оно должно быть.

У меня перед глазами пример LabVIEW. Посмотри заголовки моих тем, там с картинками. Например, будильник:

https://ibb.co/sm03yMT

Каждую секунду (1000 мсек) идет сравнение времени со временем будильника, если пришло время - будильник каждую секунду издает звуки (системный «бип»). Никакого курения мануалов по cron, никакого секса с башем. Кстати, редактирование crontab - та еще камасутра, писать в текстовом редакторе, да еще и так чтобы оно правильным оказалось… прошлый век.

Программироваие этого будильника заняло 2 минуты.

metaprog
()
Последнее исправление: metaprog (всего исправлений: 1)
Ответ на: комментарий от metaprog

LabView не использовал для разработки проектов, поэтому оценка его с моей стороны была бы как у «диванного теоретика».
Но вот API их мне нравится /очень толково/.
Что касаемо использования диаграмм LabView, для представления алгоритмов, то конечно можно их использовать, но ИМХНО они не очень наглядны.
От того и столько в ваш адрес критики.

ИМХНО графический язык программирования должен предоставлять программисту возможность использования различных объектов и
и много упрощать разработку алгоритмов.
Тривиальное сравнение ASM и Си.

PS: Раз вы выбрали стезю разработки графического языка программирования, то прежде всего вы должны разработать концепт
графического представления алгоритмов.

Владимир

anonymous
()
Ответ на: комментарий от anonymous

О графическом языке программирования в моем представлении.

Должен предоставлять объекты:

  • массивы;
  • матрицы;
  • строки;
  • списки;
  • деревья;
  • графы;
  • формы;
  • шаблоны /для формирования отчетов, более обще - какого либо цикла/;
  • 3D модели;
  • графические примитивы для записи математических формул /типа MathL/;

Любой объект internal должен создаваться /или использовать, ранее, созданные метаданные/ на основе метаданных.
Метаданные базовых объектов должен предоставить графический язык.

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

… …

PS: Где-то так /но о многом не сказал/.

Владимир

anonymous
()
Ответ на: комментарий от metaprog

Программироваие этого будильника заняло 2 минуты.

Включая запуск Лабвью и выход из него?

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

hobbit ★★★★★
() автор топика
Ответ на: комментарий от metaprog

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

Разработчик не должен мыслить категориями - «это мне не нравится».

Задача N1 для меня ныне - разработка GUI, сопряженное с метадата базой /не скрою, что некоторый опыт позаимствую у 1С 8.x/.

Ведь что такое конфигурация в понятии 1С?

Правда понятие метаданных у них не простирается далее учетных задач.
А УФ - а-ля HTML+Javascript /это шутка, но доля истины в ней есть/.

Владимир

anonymous
()
Ответ на: комментарий от metaprog

Сисадмин. Знающий крон. Я - ни тот, ни другой:)

А кто-то другой может знать крон, но не знать Лабвью.

hobbit ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Правда понятие метаданных у них не простирается далее учетных задач.

Просто для учётных задач эти метаданные более-менее нормально формализуются. А вот про другие классы задач надо крепко думать. Иначе можно создать монстра, который универсален… и при этом одинаково неудобен для решения любого класса задач. Среда разработки сред разработки сред разработки…

И даже для учётных задач можно наломать дров.

Кажется, у Баркера приводился пример универсальной модели данных из одной сущности и одной связи. Она абсолютно универсальна… и приведена в качестве примера «как не надо проектировать структуры данных».

hobbit ★★★★★
() автор топика
Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от hobbit

И даже для учётных задач можно наломать дров.

Это да.
Ориентир пока - «Не хуже чем в 1С».

Владимир

anonymous
()

Возвращаясь к парсерам

Как выяснилось, в старом gccxml также поддерживается ключ -I — просто в мане он не описан.

hobbit ★★★★★
() автор топика
Ответ на: комментарий от hobbit

Лабвью вроде несложное, но первый толчок все же нужен. И когда чуток освоился - все становится понятным, достаешь блоки и содиняешь их, новые либы даются легко, и чаще всего даже без прочтения мануалов (хватает короткой контекстной справки, всплывающей при наведении мышью).

В Метапроге, как ты уже знаешь, я планиную интерактивную обучалку. Да что там планирую - в прототипе уже есть!

А вот крон и прочие консольные утилиты ты черта с два поймешь, не выкурив мануалы, верно?

metaprog
()
Последнее исправление: metaprog (всего исправлений: 1)
Ответ на: комментарий от anonymous

Сборка run time dll для C++ в Visual Studio 2013 происходит без проблем.
https://www.antlr.org/download/antlr4-cpp-runtime-4.7.2-source.zip

The extension for ANTLR4 support in Visual Studio code. https://marketplace.visualstudio.com/items?itemName=mike-lischke.vscode-antlr4

Завтра, а если не поленюсь, то сегодня попробую какое-нибудь demo собрать.

Владимир

anonymous
()
Ответ на: комментарий от metaprog

Не унывайте.

«Задайте вопрос на русском форуме и вам расскажут, какой вы мудак, все ваши родственники и ваша собака»

Владимир

anonymous
()
Ответ на: комментарий от anonymous

пробовал. с AST там работать легко и просто. например есть toStringTree() метод, который позволяет распечатать AST в лисп-подобном виде S-выражений (с немного не правильным форматированием, так что далее это нужно либо засунуть в indent, либо в емакс и скриптом для лисп-форматирования, либо пользоваться не этим методом, а обходить AST вручную распечатывая, либо через StringTemplate).

алсо, обратите внимание на StringTemplate. и примеры написания своих pretty printer-ов, транспиляторов. можно закачать AST на одном языке, распечатать в другом. например, сделать многоязычное на входе, многоязычное на выходе.

cpp target, C# target, python target вполне себе сносные. так что не только явой можно пользоваться.

anonymous
()
Ответ на: комментарий от anonymous

алсо, демо удобно тыкается в ANTLRWorks, где этот AST можно пошагам отладить, посмотреть, распечатать, обработать. ещё в третьем был GUnit про юнит-тестирование грамматик, нечто вроде StringTemplate: задавались тесты правильные и неправильные, специальной тулзой и грамматикой тестов можно было перехватить «распарсено ОК», «распарсено не ОК», «выскочило исключение» и посмотреть в кусок AST и семантику при исключении.

anonymous
()
Ответ на: комментарий от anonymous

ИМХНО графический язык программирования должен предоставлять программисту возможность использования различных объектов и и много упрощать разработку алгоритмов. Тривиальное сравнение ASM и Си.

сравнение с LabView не совсем тривиальное, поскольку это dataflow визуальный язык. то есть, все блоки выполняются параллельно и асинхронно, по готовности данных.

была какая-то публикация про то, как на STEP EXPRESS ISO 10303 студенты написали какой-то dataflow язык. описали модель данных, параметризации (в STEP EXPRESS это ОО СУБД с наследованием и/или AND/OR деревьями по предикатам типов + вычисляемые функциями параметры) для связей dataflow блоков, далее на этом сконструировали свой pipeline типа node editor в 3D с материалами/видеоредакторе (том же Houdini где на нодах всё).

какие-то расчётные вещи делали, с универсально конфигурируемым dataflow pipeline.

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

правда, автор metaprog-а всю эту динамичность толком не использует, компилируя в обычную императивную парадигму.

PS: Раз вы выбрали стезю разработки графического языка программирования, то прежде всего вы должны разработать концепт графического представления алгоритмов.

которого у него толком нет – проводки между блоками и неимперативный dataflow.

anonymous
()
Ответ на: комментарий от anonymous

ещё есть Spoofax (IDE на базе Eclipse, включающее «комплект всё-в-одном») на основе Stratego/XT.

там оно дальше от голого AST и парсинга, больше в сторону «проективного структурного редактора» типа JetBrains MPS. то есть, проще написать IDE с семантически корректным DSL и эту семантику указать.

идеологически, у этого Elco Dolstra далее переписывание термов на основе правил и эквивалентных преобразований. сайт program-transformation в эту же тему. грамматика и тулзы из Stratego/XT ближе к BNF, писать и отлаживать их проще.

anonymous
()
Ответ на: комментарий от anonymous

https://github.com/antlr/antlr4/blob/master/doc/cpp-target.md

Когда утверждают, что ANTLR «медленный», о чем идет речь?
О парсинге грамматики и генерации *.cpp listener или
сгенерированный код listener медленно распознает лексемы?

Если listener «медленный», то почему его солидные фирмы используют?

Владимир

anonymous
()
Ответ на: комментарий от anonymous

ХЗ, сильно зависит от грамматики. сам алгоритм LL(*) у ANTLR чуть медленнее классического LALR и примеров из учебника типа Оберона или Паскаля. но не сильно медленный по сравнению с тем же PEG или GLR или ещё какой META.

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

anonymous
()
Ответ на: комментарий от anonymous

Да об этом.

«Наглость как известно, второе счастье».
Какой tools для работы с грамматиками используете?

Владимир

anonymous
()
Ответ на: комментарий от anonymous

Спасибо за ответы.

Шутка.

Для ANTLR уже грамматик сто разработали - «Не пропадать же добру?».

Владимир

anonymous
()
Ответ на: комментарий от anonymous

пользуйтесь на здоровье :))

для 1C v7.7 под Antlr3 я сам когда-то на коленке разработал такое

работает. в production потом добавил GUnit тесты и семантические предикаты. под Antlr v4 нужно немного её допилить будет.

и транспилятор «1Cv7 to LISP» – простенький на коленке примерно такой будет.

полноценный нужно писать на StringTemplate с распечаткой в какую-нибудь Ada :)))

ну и для нормального продакшен кода :)) нужно бы всё это допортировать на 1Cv8, Antlr v4. :))))

anonymous
()
Ответ на: комментарий от anonymous

ещё в тему универсальных моделей данных

Правда понятие метаданных у них не простирается далее учетных задач.

например, здесь про STEP EXPRESS – это сделано грамотно: универсально, расширяемо, машиночитаемо и машиногенерируемо:

язык моделирования ОО данных (STEP EXPRESS – текстовый, EXPRESS-G – графический), предназначенный для универсального, машиночитаемого, интегрированного онтологически (согласно предметной области) представления данных, при этом можно задавать и отношения между моделями данных (модель-метамодель), и обобщения (анализ-синтез-порождение) и обычные (часть/целое, предок/потомок), то есть: отношения в схеме данных.

при этом есть инструментарий, позволяющий кодогенерировать интерфейсы взаимодействия с такой ОО СУБД, в конкретные языки программирования. есть стандартный ORM (SDAI). есть проверка модели на соответствие схемы, чтобы новую модель в старую схему несовместимую загрузить невозможно было. модели параметризуемые, с вычисляемыми параметрами – есть функции, процедуры и правила соответствия. есть стандартный формат файла переноса (Part 21, текстовый). есть примеры для XML представления, графического представления (Express-G) и отображения для конвертации (Express-M).

далее на самом языке описания моделей данных STEP EXPRESS в ISO 10303 описывается 10500 (ну чуть меньше :) «прикладных протоколов». то есть, если EXPRESS – это схема предметной области, «онтология» в виде ОО субд и её схемы данных, то AP это интерфейсы, которым должно API работы с этими данными соответствовать. далее это API для стандартных предметных областей стандартизируется, унифицируется, онтологизируется стандартные структуры метаданных.

ну вот, собственно оно самое и есть:

  1. графический язык моделирования, правда, данных, а не алгоритмов
  2. правильно онтологически стандратизированная метадата база
  3. инструментарий работы с различными СУБД и языками программирования в этой технологии.

далее к этому нужно прикрутить нечто типа программируемой вики с настраиваемыми формами документов и процессами либо что-то вроде «literate programming», наподобие Emacs org-mode. и получить исполняемые в этой среде универсальные модели и метамодели, данных, процессов, и их представлений.

и потом сверху графический редактор типа САПР прикрутить.

а то тут изобретают велосипеды, в том же 1С, например. со своими псевдо «объектами», нисколько не расширяемыми и не машиночитаемыми, не интегрируемыми, не особо расширяемыми и универсальными.

а ведь по отдельности уже все средства для этого есть – только нужно собрать их все вместе, в удобном виде.

в виде какого-то MetaCASE «производства средств производства» :)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.