Нарушитель
54 / 55 / 8
Регистрация: 01.07.2014
Сообщений: 1,021
|
|
1 | |
Различия использования регулярных выражений и генераторов парсеров в GCC и MSVC29.05.2016, 00:34. Показов 1067. Ответов 12
Метки нет (Все метки)
Я слышал что G++ и MSVC используют lex и bison для построения дерева токенов и парсинга. А клэнг свой какой то язык, который обрабатывает бэкэнд. Недавно со знакомыми кодерами возник интересный разговор: Правда ли что регулярки и генераторы парсеров медленее чем обычный нативный код. На деле оказалось что нет, и даже FPC быстрее кланга оказался.
Собственно и вопрос, правда ли что оба эти компилятора используют генераторы парсеров и несмотря на совсем незначительные потери произв-сти, работают медленее чем если бы парсились на лету(как в TCC к примеру) а не компилировались сначала регулярки а потом уже проводился анализ.
0
|
29.05.2016, 00:34 | |
Ответы с готовыми решениями:
12
компиляция gcc и MSVC Портирование ассемблерной функции с MSVC на GCC Объясните устройство сложных вложенных выражений-генераторов Различия в yasm и gcc assembler |
29.05.2016, 10:00 | 2 |
Если под словом "используют" подразумевается "сам компилятор написан с использованием", то можно поглядеть на исходники gcc, там есть какие-то файлы с расширением *.l, а в старых версиях были и файлы с расширением *.y (если я ничего не путаю). Когда-то я их изучал и сложилось впечатление, что там реализовано лишь некоторое подмножество языка. Да и не было полной уверенности, что оно входит именно в состав компилятора, а не в состав какой-нибудь утилиты, которая используется при сборке компилятора
Но тут есть два момента 1. Парсер в компиляторе занимает дай бог 1% времени исполнения. А потому скорость работы парсера в пределах +-100% роли не играет, а потому пофигу на чём его писать 2. lex/bison годны для написания примитивных парсеров. Синтаксис таких монстров как Си++ слишком сложен, для того, чтобы с ними работать на lex/bison. Парсер ведь не только должен распарсить, но ещё и грамотно выдать пользовательские ошибки, причем после выдачи ошибки современные компиляторы продолжают парсить (т.е. выдают несколько ошибок за раз). На lex/bison, думается, опухнешь это делать (правда не уверен в этом на все 100%) Добавлено через 2 минуты Что касается MSVC, то я более чем уверен, что тем не может быть никаких lex/bison тупо по политическим соображениям
1
|
Нарушитель
54 / 55 / 8
Регистрация: 01.07.2014
Сообщений: 1,021
|
|
29.05.2016, 12:33 [ТС] | 3 |
Evg, есть один компилятор PHP в Java - JPHP, там все на регулярках, и работает вполне быстро. А как известно PHP имеет много общего с обычным C и немного C++(ООП в PHP не полное, шаблонов нет)
Добавлено через 49 секунд В википедии так и написано что MSVC и GCC используют лекс и бизон.
0
|
29.05.2016, 13:26 | 4 |
Слабо понимаю, каким боком сюда относятся регулярные выражения
Про MSVC я могу только догадываться, т.к. у них исходник закрытый. Википедия - это не то место, чему можно слепо доверять. На месте микрософтеров я бы не использовал gnu'тый софт по политическим соображениям В исходниках gcc действительно есть файл от lex'а (gengtype-lex.l). Но файлов для bison'а я не вижу. Файл от lex'а довольно маленький, вряд ли он относится к самомУ компилятору. Судя по названию, он парсит какой-то из файлов *.def Я исходники смотрел тут https://github.com/gcc-mirror/gcc Более предметно можно скачать какой-нибудь исходник и собрать его. По логам сборки будет видно, для чего используется lex Парсер для Си, судя по названию - это файл gcc/c/c-parser.c, для Си++ - gcc/cp/parser.c
1
|
Нарушитель
54 / 55 / 8
Регистрация: 01.07.2014
Сообщений: 1,021
|
|
29.05.2016, 14:18 [ТС] | 5 |
Evg, парсер C там фронтэнд только. Остальное за бэкэндом спрятано.
Добавлено через 2 минуты Охренеть. Метр кода на парсер. Готовый генератор анализаторов и парсеров для Java(ANTLR) и то меньше весит(около 700кб)
0
|
gng
|
29.05.2016, 20:18
#7
|
Не по теме: Пока, вроде, только один раз их в этом уличили. Года два назад кто-то дотошный путем анализа кода обрнаружил в закрытой проге MS код распространяемый под GPL. MS, надо сказать, повел себя достойно. Оправдались тем, что это сделали нанятые сторонние кодеры без ведома компании. И, как того требует лицензия, открыли код всего своего продукта по лицензией ГПЛ.
0
|
Нарушитель
54 / 55 / 8
Регистрация: 01.07.2014
Сообщений: 1,021
|
|
29.05.2016, 21:18 [ТС] | 8 |
Evg, GCC делится на несколько этапов: фронтэнд и бэкэнд.
Фронтэнд анализирует код и выстраивает дерево токенов, а бэкэнд уже генерирует листинг на асм и пинает его в GAS
0
|
Нарушитель
54 / 55 / 8
Регистрация: 01.07.2014
Сообщений: 1,021
|
|
30.05.2016, 10:59 [ТС] | 10 |
Evg, черт его знает, не каждую же строку парсить?
0
|
Игогошка!
1801 / 708 / 44
Регистрация: 19.08.2012
Сообщений: 1,367
|
|
30.05.2016, 11:23 | 11 |
VC - я не в курсе. GCC использовал когда-то давно, но сейчас, понятное дело, нет.
У Clang ручной парсер. А язык (точнее IR), который идет на вход бэкенду, тут вообще не в тему. Все зависит от того, какая грамматика, как написан код, насколько подробные сообщения об ошибках, и тд. Факт, грамматика С++ не подходит для адекватного разбора и диагностики flex/bison'ом.
0
|
Нарушитель
54 / 55 / 8
Регистрация: 01.07.2014
Сообщений: 1,021
|
|
30.05.2016, 11:49 [ТС] | 12 |
ct0r, на них же разбирают пыху, бэйсик и кучу других ЯП
0
|
Игогошка!
1801 / 708 / 44
Регистрация: 19.08.2012
Сообщений: 1,367
|
|
30.05.2016, 13:19 | 13 |
0
|
30.05.2016, 13:19 | |
30.05.2016, 13:19 | |
Помогаю со студенческими работами здесь
13
Формула регулярных выражений Тестер регулярных выражений Шаблон регулярных выражений Несколько регулярных выражений Конструктор регулярных выражений Синтаксис регулярных выражений Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |