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)

Ответ на: комментарий от byko3y
  • контролируемое высвобождение данных (но само определение точки высвобождения сделано отвратительно);

Вот что это за хрень «определение точки высвобождения данных»? Я могу вызвать delete когда захочу.

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

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

Всё так, кроме того что произошел провал. Есть сильное подозрение, что он был бы без совместимости с C. Точнее, был бы еще один красивый язык в истории. А так - один из столпов индустрии в прошлом и отчасти сейчас (безотносительно того, насколько он хорош).

AT&T в то время схавало бы любой кусок дерьма - лишь бы он вонял меньше, чем Си. Я меряю язык по его фактическому качеству, а не по коммерческому успеху - этот коммерческий успех дал нам огромную гору текущего, падающего, и уязвимого к удаленному выполению софта.

Всё равно непонятно, в чем претензия? Нужно было просто ничего не делать? Лучше бы весь этот падающий/уязвимый софт оставался на C?

У меня, лично, только одна претензия - к тому, что кто-то называет C++ хорошим языком. Для меня «провал» - это когда вместо одного куска дерьма ты начинаешь использовать другой кусок дерьма. Как я понимаю, для тебя «провал» - это когда язык не покупается/не продается.
Да, AT&T нужно было что-то предпринимать, да, подошло бы что угодно, да, получилось не очень, но всё же лучше, чем Си - я согласен с этим. Но что C++ - это хороший язык, веха прогресса, успех в технологиях софтостроения - нет, не согласен. Провал в технологиях, успех на рынке - так пойдет?

Сделать еще один несовместимый язык - это и есть примерно «ничего». Такого было сделано навалом, а толку.

Алеу, так он и есть несовместимый. Формальная совместимость - это маркетинговый конек. В итоге из Си кресты все равно использовать не сможешь, но будет уже поздно - и ты просто подставишь очередной костыль, чтобы сдать проект, как делал это сто раз.

Это не практичность - это продажа. Потому что заказчик обычно - дебил

Да кто заказчик-то? И где деньги?

AT&T хорошо заработал, продавая Cfront. Да-да, тот самый допотопный, с примитивными классами и транспиляцией в Си.

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

Проблемы с безопасностью языка Си в C++ окончательно решены не были.

Это не новость. Но если их стало меньше - уже хорошо.

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

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

И сколько этих компиляторов C++ поддерживают последний актуальный стандарт C++?

C++, наверное, 4…

С С ситуация лучше, точное число не скажу, но по крайней мере оба этих самобытных компилятора заявляют о поддержке С11/С17

http://ladsoft.tripod.com/orange_c_compiler.html

https://www.pellesc.de/index.php?page=changelog&lang=en

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

контролируемое высвобождение данных (но само определение точки высвобождения сделано отвратительно);

Вот что это за хрень «определение точки высвобождения данных»? Я могу вызвать delete когда захочу.

Пардон, не дописал «автоматическое». C++ упрощает высвобождение ресурсов за счет более безопасной автоматики вместо ручного delete - это устраняет сразу огромное кол-во ошибок ручного управления памятью, свойственного программам на Си.

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

Но что C++ - это хороший язык, веха прогресса, успех в технологиях софтостроения - нет, не согласен. Провал в технологиях, успех на рынке - так пойдет?

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

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

В отличие от «типа простых языков» у С или С++ сотни различных компиляторов.

Вот именно. Это сотни миллиардов долларов на разработку кучи вариантов компиляторов и кучи вариантов стандартных библиотек. А у кристала есть только одна библиотека и один компилятор.

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

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

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

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

Это сотни миллиардов долларов

Виртуальных, реально там жалкие миллионы.

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

AT&T хорошо заработал, продавая Cfront. Да-да, тот самый допотопный, с примитивными классами и транспиляцией в Си.

Comeau C++ вроде до сих пор продаётся, с транспиляцией в Си

позиционируется как модельный референсный компилятор для самораскрутки если на вашей платформе даже gcc никакого нет (например, plan9, хотя там есть).

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

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

Не херня только результат, а путь к результату может быть и через шаблоны, и через скобки, и через голый С. А тот, кто придирается к ЯП, априори занимается херней.

П.С. сейчас прикручиваю QuickJS вместо V8 для скриптоты, Беллар - гений, у мужика продуктивность целой корпорации. Причем на голом С.

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

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

Реализация Си по спецификациям чего-то уровня GCC/Clang будет огромна. ANSI C - да, простенький, но и убогий. Есть фортран, есть паскаль, есть алгол - они тоже просты и как язык, и в плане реализации. Как бы при чем тут Си? К Си у меня претензии только в том плане, что это плохо спроектированный язык, который даже сложно распарсить, из-за чего для него повсеместно применяются рукописные парсеры под конкретно один Си, в том числе и упомянутый тобой LCC, на базе которого сделан Pelle C.

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

Не херня только результат, а путь к результату может быть и через шаблоны, и через скобки, и через голый С.

А если сам путь оказывается сложным из-за необходимости использовать неудобные инструменты для решения поставленных задач, и получившаяся лапша из шаблонов абсолютно нечитаема и компилитуется час? Или это все неважно?

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

кстати, можешь насчёт JS разъяснить. я правильно понимаю, что из-за контекстов выполнения, этих scope chain, event queue и того что жопаскрипт – однопоточный, там по сути GIL в этих контекстах выполнения: события из очереди событий и обработка коллбеков будут отработаны не когда запущены, а когда стек контекстов выполнения опустошится, дойдя до глобального?

и это по сути GIL в блямбды и асинхронщину завёрнутый. и принципиально однопоточный?

кстати, чо там с wasm насчёт этого, что-нибудь меняется?

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

Не херня только результат, а путь к результату может быть и через шаблоны

per rectum ad astra!

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

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

Мастурбировать - это нормально, все люди этим занимаются.

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

А если сам путь оказывается сложным из-за необходимости использовать неудобные инструменты для решения поставленных задач, и получившаяся лапша из шаблонов абсолютно нечитаема и компилитуется час? Или это все неважно?

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

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

Comeau C++ вроде до сих пор продаётся, с транспиляцией в Си
позиционируется как модельный референсный компилятор для самораскрутки если на вашей платформе даже gcc никакого нет (например, plan9, хотя там есть).

Рынок-рыночек, придет и всех порешит. Мне будет сложно перечислить кол-во бесполезного мусора, которое получило рыночный успех. Самым известным, наверное, будет Java, которая не принесла ни одной новой технологии, а была лишь компиляцией старых технологий, сделанной с упором на самые популярные, а не самые эффективные решения.

К слову, AT&T нынче в IT уже ничего не значит, а Sun и вовсе погибла. Роль этих фирм была проста: задать всем единый стандарт, пусть и плохой, но единый - и сдохнуть.

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

сейчас прикручиваю QuickJS вместо V8 для скриптоты, Беллар - гений, у мужика продуктивность целой корпорации. Причем на голом С.

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

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

кстати, можешь насчёт JS разъяснить. я правильно понимаю, что из-за контекстов выполнения, этих scope chain, event queue и того что жопаскрипт – однопоточный, там по сути GIL в этих контекстах выполнения: события из очереди событий и обработка коллбеков будут отработаны не когда запущены, а когда стек контекстов выполнения опустошится, дойдя до глобального?
и это по сути GIL в блямбды и асинхронщину завёрнутый. и принципиально однопоточный?

Да, JS принципиально однопоточный. Это слишком глубоко въелось в прикладные реализации, хотя, казалось бы, базовые конструкции языка не обязывают прямо-таки всегда безоговорочно быть однопоточным.

кстати, чо там с wasm насчёт этого, что-нибудь меняется?

Он вообще никак не связан с JS. Да, поддержка потоков есть, уже год как.

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

Смотря что конкретно о них спросят.

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

К слову, AT&T нынче в IT уже ничего не значит, а Sun и вовсе погибла. Роль этих фирм была проста: задать всем единый стандарт, пусть и плохой, но единый - и сдохнуть.

Юникс и ява это плохой стандарт? А что тогда остается хорошего?

Liz812
()

Сначала использовал meta-parse, потом наваял своё. Где-то в исходниках Яра можно найти.

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

Javascript - очень простой язык, даже в самой последней спецификации.

Он то простой, но если искать реализации - это либо монстры, либо недоделки и поделки, либо что-то специализированное с невменяемым API. А в QuickJS все сделано так, как сам бы для себя писал.

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

У меня, лично, только одна претензия - к тому, что кто-то называет C++ хорошим языком

Ну это фанатики. Я считаю его… достаточно неплохим. С поправкой на то, что я на нем десяток лет и адаптировался под него. И с учетом новых стандартов. Я бы хотел что-то вместо, но его у индустрии нет.

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

Алеу, так он и есть несовместимый. Формальная совместимость - это маркетинговый конек.

Да ну, несовместимости там незначительные. Скорее, наоборот - формально он несовместим, а по факту - достаточно хорошо.

В итоге из Си кресты все равно использовать не сможешь

Мм… Совместимость только в одну сторону.

AT&T хорошо заработал, продавая Cfront.

Я думал, мы про Бьярна лично. Вряд ли он тогда хорошо заработал, он скорее за идею.

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

Юникс и ява это плохой стандарт? А что тогда остается хорошего?

POSIX вполне неплох для своих лет. Нужно понимать, что юникс - это мелкая ОС плюс набор мелких утилит. Бесполезно писать на том же языке (Си) что-то другое, но использовать интерфейс (posix) - очень даже удобно и годно. Сейчас, правда, posix уже безнадежно устарел.

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

Он то простой, но если искать реализации - это либо монстры, либо недоделки и поделки, либо что-то специализированное с невменяемым API. А в QuickJS все сделано так, как сам бы для себя писал.

Прежде всего, на кой черт тебе JS? Лучший маленький встраиваемый язык - это Lua.

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

Прежде всего, на кой черт тебе JS? Лучший маленький встраиваемый язык - это Lua.

Не мне, пользователям. JS и Python это то, что востребовано. Lua еще никто не просил.

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

Спросят меня на экзамене про рекурсивные шаблоны, нужно сказать что это херня?

Скажешь, что вместо того, чтобы практиковаться с C++, траповал на ЛОР-е.

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

Я бы хотел что-то вместо, но его у индустрии нет.

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

Если кто-то считает Бьярна или весь WG21 идиотами - он просто не в теме. Они делали и делают офигительную работу в кошмарных условиях. Поэтому результат часто так себе.

Да, у них кошмарные условия - им приходится работать с C++. Я бы давно уже вскрыл себе вены на их месте.

Да ну, несовместимости там незначительные. Скорее, наоборот - формально он несовместим, а по факту - достаточно хорошо.

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

Я думал, мы про Бьярна лично. Вряд ли он тогда хорошо заработал, он скорее за идею.

Ну в 1982, может и за идею. А последние лет 30 он очень хорошо зарабытывает на своем статусе создателя великого и могучего C++.

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

Для жабистов у ANTLR основное преимущество в том, что он сам на жабе. А для остальных «нормальных людей» это является «фатальным недостатком», ибо нерационально тащить jvm-монстра только ради генерации парсера.

Что касается уровня «велосипедостроения», то дело обстоит несколько иначе:

  • чуть менее чем во всех проектах, где парсинг достаточно важен, используются свои «велосипеды» (antlr не используется в graal и т.д.).
  • в среднем в жабе гораздо меньше проектов где производительность или потребление ресурсов настолько важны, чтобы экономить на отказе от ANTLR в пользу своих специализированных «велосипедов».
Deleted
()
Ответ на: комментарий от Liz812

Спросят меня на экзамене про рекурсивные шаблоны, нужно сказать что это херня?

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

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

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

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

man:

https://caniuse.com/#feat=serviceworkers (фича для кеширования и оффлайн доступа сайта, чтобы можно было работать с сайтом когда инет пропал)

https://caniuse.com/#feat=webworkers (фича чтобы сайт не лагал когда выполняются какие-то расчёты на сайте)

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

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

но например асинхронный MVC/MVVM для некоего условного метапрога на MVC компонентах (асинхронно исполняемых на каких-нибудь зелёных потоках) на яваскрипте всё ещё запилить решительно невозможно?

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

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

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

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

ничто не мешает отладить сначала грамматику в jar реализации ANTLR, а потом запилить свой бекенд для компилируемого языка (и в поставке их несколько уже есть).

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

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

А делать запросы(fetch) к базе и промежуточные преобразования можно в webworker’ах

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

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

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

Да, у них кошмарные условия - им приходится работать с C++

В целом, так и есть %)

Ну так и паскаль совместим, дальше что?

Чего-то я не понимаю…

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

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

также непонятно, зачем нужен DOM, если можно без него (и все эти костыли типа virtual DOM, shadow DOM и прочее)? ещё один GIL вокруг AST подправленного под стандарты?

например, Literate Programming модель/метамодель: есть именованные «блоки кода» с расширяемыми шаблонами, и «блоки данных», и «кусок документации» вокруг них. если предположить что подстановки возможны не только «текст в текст» как просто именованные чанки, но и нечто вроде макросов лиспа, функции времени компиляции с параметрами-метапеременными, то на это можно натянуть любую метамодель, хоть с метаклассами, хоть с наследованием блоков данных, хоть произвольную, не обязательно иерархическую онтологию.

в общем: про web тоже есть ощущение что можно было лучше сделать.

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

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

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

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

но все эти потоки выполняются всё равно в однопоточном интерпретаторе JS?

В вебворкере можно запустить ещё вебворкеры, то есть распаралелить внутри дальше…

В вебворкерах не нужно думать о синхронизации, потому что её там нет. Все данные которые мы передаём в вебворкер они копируются. А глобальные переменные там недоступны, поэтому и недоступен DOM.

https://developer.mozilla.org/ru/docs/DOM/Using_web_workers

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

ничто не мешает отладить сначала грамматику в jar реализации ANTLR, а потом запилить свой бекенд для компилируемого языка (и в поставке их несколько уже есть).

Это не нужно вне ниши жаба-языков. Поэтому ANTLR почти никто не использует без жабы. И по той-же причине С++ бэкенд там адово кошмарен.

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

А вот теорию подучи.

Как вы с анонимом сразу сагрились-то. :)

Я же неспроста слово «парсер» поставил в кавычки. Речь идёт о том, что если код выдержан в определённом стиле (к которому программу можно привести автоматом, каким-нибудь astyle) — на написание полноценного парсера можно забить. И никакая теория этого не опровергнет. Полноценный продукт так делать, конечно, нецелесообразно. Но для внутреннего употребления — вполне себе решение.

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

В общем, с CastXML получилось лучше, чем с оригинальным GCC-XML. У него есть ключ -I с общепринятым смыслом. Подставил в него все нужные пути, получил на выходе XML. Для моего старого исходника с использованием Qt4:

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

XML немного неопрятной структуры, но это по-любому лучше, чем с нуля парсер писать. Второй вопрос можно считать решённым.

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