McSeem2 wrote:
> C>Вообще-то VC7.1 почти полностью совместим со Стандартом, и диагностика > C>ошибок в шаблонах — вполне нормальная. Когда я переносил свой проект, > C>который писался полгода, на GCC — проблем с шаблонам не возникло (а > их у > C>меня там мнооого). > VC7.1 страдает практически такой же болезнью, что и VC6 — он не толком > не проверяет синтаксис шаблонов до момента их реального использования. > При написании библиотек это создает проблемы. Даже отсутствие > банальной ";" в нужном месте — пропускает. GCC и Intel — диагностируют > нормально.
Однако, когда шаблоны все-таки инстанцируются, то происходит полная
проверка.
ЗЫ: я так к это "фиче" привык, что уже забыл про нее. Когда я пишу
шаблоны, то в cpp всегда ставлю явное их инстанцирование.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[7]: Theory and Techniques of Compiler Construction
Здравствуйте, McSeem2, Вы писали:
MS>А все началось с того, что в C++ разрешили использование сущностей вперед их декларации...
С точки зрения разборщика это не такая уж и сложная задача. Есть несколько решений как разбирать классы. Мне наиболее удобным кажется решение отделить семантический анализ от синтаксического. Т.е. сначала пройти по классу, разобрать его синтаксически, т.е. построить дерево вывода, а затем уже по этому дереву пройтись семантическим анализатором с поиском имен т.д. Понятно, что в этом случае взять и в лоб использовать бизон не получается, надо чуть более хитрую программу писать. Но, принципиально, ничего сложного в этом нет. В случае шаблонов сложность разбора повышается, т.к. с поиском имен еще больше проблем. Сам я компилятор си++ не писал, но судя по высказыванием людей, которые это делали, есть две больших проблемы:
1. Грамматика си++ не укладывается в прокрустово ложе LR(k)-анализатора. Конечно, можно попытаться перенести многие свойства грамматики на уровень ручного кодирования — "семантический анализ". Но, оказывается, для си++ слишком много приходится переносить, очень неудобно и нехорошо. Поэтому, опытные люди пишут компилятор для си++ вручную, т.е. такой расширенный LL(k)-парсер с откатами, или при помощи более продвинутых алгоритмов синтаксического анализа, таких как GLR. Недавно в юзенет конференции, посвященной компиляции, развернулась дискуссия на эту тему. Айра Бакстер, архитектор компании Семантик Дизайн, рассказала, что их компилятор си++, как и многих других языков, реализован с помощью GLR генератора, написанного ими же. И никаких проблем с реализацией они не имели. Автор этого топика имел дискуссию с самим Квином Тайлером Джексоном относительно того, какую часть языка выражать грамматикой, а какую передавать в "семантический анализ". Квин отстаивал формальный подход, основанный на традиции, а я уговаривал его, что здесь не должно быть никаких правил, кроме одного — удобства программирования. Если мне удобно перенести какую-то часть языка в "скмантику", то я просто это и делаю, а остальную реализовываю посредством формальных грамматик. Хочется надеяться, что он меня услышал. В общем, для си++ удобно иметь синтаксический анализатор, который в состоянии разобрать ту грамматику, которая прописана в стандарте. Построение другой грамматики — это уже уступка прихотям конкретного генератора разборщика.
2. Пространства имен в си++ очень сложны и не укладываются в рамки простого "монитора". Для реализации, вероятно, это самая сложная вещь. Кроме текущей таблицы, связанной с данной областью видимости, подключаются еще другие таблицы, через декларацию using или поиск, зависящий от аргументов функции. Ну там еще куча проблем. В принципе, и здесь ничего сверх сложного нет, просто надо использовать нестандартные методы, которые в книжке Вирта не описаны. Но тем, по моему мнению, и интереснее.
Re[8]: Theory and Techniques of Compiler Construction
A>>PS Кстати по результату пролистыванияне осталось впечатления что книга очень уж простая и сугубо практическая F>У меня есть такая. Кому надо — вышлю по запросу в мыло. Объем 1.2 Мб в zip
Если можешь, то шли на eroshkin<собака>ispras.ru .
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[5]: Theory and Techniques of Compiler Construction
Здравствуйте, VladD2, Вы писали:
VD>Ну, трешка похоже просто будет практически идеальным построителем парсеров. А 2.х просто довольно мощьный продукт. А есть там много чего. Декларативное заглядывание вперед (правда становится не актуальным в следующей версии). Декларативное построение АСТ. EBNF. Автоматическое пуравление памятью (ну, это скорее Ява себя проявляет).
Это-то да. Но я спрашивал в свете недавнего обсуждения возможности раширения LL(k)-анализатора так, чтобы он имел возможно разбирать параллельно альтернативы, даже если они не укладываются в LL(k) для любого, сколь угодно большого k. Кто-то, не помню кто, дал ссылку на третью версию ANTLR. Я пошел по ссылке, прочитал кучу блогов, но сумел вынести оттуда только одно: ничего про параллельный разбор там нет и единственное улучшение — это использование регулярных выражений в предосмортрах. Идея это не новая, придумана была еще в 60-х годах. Суть ее такова: вместо использования конкретной строки длиной 1 или два символа в качестве предосмотра, использовать класс строк, вводимых с помощью регулярных выражений. Как известно, в LL(k)-анализе практически единственным способом различений контекста является исползование предосмотров. Например, в грамматике
A --> B | C
B --> NUMBER D
C --> STRING D
мы можем выбрать, какую альтернативу для разбора символа A использовать, заглянув на один симовл вперед. Если этот символ есть NUMBER, то выбираем A --> B, если STRING, то выбираем A --> C, если ни то ни другое — возвращаем ошибку. Проблема возникает, когда мы имеем грамматику типа
A --> B | C
B --> NUMBER D
C --> NUMBER D
D --> STRING E
D --> '+' E
Здесь уже LL(1) не подойдет, надо знать два символа впереди, чтобы различить альтернативы A --> B и A --> C. Так вот, а если попытаться вместо конкреных строк предостмотров использовать регулярные выражения как множество строк? Было бы удобно, хотя совершенно не увеличило бы мощность разборщика. Кроме того, сами правила тоже можно представить посредством регулярного выражения, т.е. автомата, и, тем самым, улучшить скорость разборщика. Конечно, надо еще, чтобы сами правила имели такой, "регулярный" вид. Я, конечно, могу ошибаться, просмотрел документы по ссылкам мельком и мог неправильно понять, но улучшения синтаксического анализатора я там не увидел. Вообще, наряду я вненсениям последних достижений теории компиляции в генератор, разработчики ANTLR не хотят использовать последние достижения в области синтаксического анализа. Это, несомненно, обедняет систему. Класс языков, который может быть разобран с помощью этого инструмента, сейчас уже совершенно неудовлетворителен.
Re[2]: Theory and Techniques of Compiler Construction
Здравствуйте, andyJB, Вы писали:
JB>Судя по контенту, довольно поверхностно. К тому же затронуты не самые интересные темы — Мучник, имхо, в качестве референса пополезнее будет. В общем, книжка студентам 1-3 курса.
Енто что такое ?
Re[3]: Theory and Techniques of Compiler Construction
Здравствуйте, Aviator, Вы писали:
JB>>Судя по контенту, довольно поверхностно. К тому же затронуты не самые интересные темы — Мучник, имхо, в качестве референса пополезнее будет. В общем, книжка студентам 1-3 курса.
A>Енто что такое ?
Библия специалистов по генерации кода.
Re[8]: Theory and Techniques of Compiler Construction
Здравствуйте, fplab, Вы писали:
F>Здравствуйте, Aviator, Вы писали:
A>>Здравствуйте, mefrill, Вы писали:
M>>>Здравствуйте, Aviator, Вы писали:
A>>>>Часом не DICK GRUNE, CERIEL JACOBS "PARSING TECHNIQUES" ? Если не эта приведите пожалуйста ссылочку Очень интересно было бы ознакомится .
M>>>Ага, та самая.
A>>К большому сожалению так и не читал эту книжку, хотя давно уже валяется Выс считаете что стоящая книга и если заниматься компиляторами то необходимо прочитать ?
A>>PS Кстати по результату пролистыванияне осталось впечатления что книга очень уж простая и сугубо практическая F>У меня есть такая. Кому надо — вышлю по запросу в мыло. Объем 1.2 Мб в zip
заранне большущее спасибо — qrilka (at) gmail.com
Re[4]: Theory and Techniques of Compiler Construction
Здравствуйте, eao197, Вы писали:
E>В общих словах ANTLR -- это генератор нисходящих парсеров для LL(1) грамматик.
В том то и дело что не LL(1), а LL(k), причем с большим k (3-8) — используется эвристика которая позволяет уменьшить
сложность предпросмотра.Где-то на сайте можно найти диссертацию автора целиком по этой теме.
Re[6]: Theory and Techniques of Compiler Construction
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Гм... Мне лень лезть в спецификацию всевозможных оберонов... Предлагаю поверить в этом Сергею Губанову. Он утверждает
, что для использования класса в Обероне, предварительное объявление не требуется.
В Обероне определение класса разделено на две части: сначала описывается тип записи, а потом описываются процедуры связанные с этим типом.
Более того:
1) Сначала полностью описываются все типы, а уже потом описываются все процедуры. Вперемешку нельзя. (Хотя некоторым это не очень нравится. Так, например, Трурль "подкрутил чуток" компилятор BlackBox-а и сделал возможным писать типы и процедуры вперемешку.)
2) Для использования еще не определенных процедур требуется их предварительное объявление.
MODULE Test;
TYPE
Bar = POINTER TO RECORD
foo: Foo
END;
Foo = RECORD
bar: Bar
END;
(* Предварительное объявление процедуры DoAnother связанной с типом Bar (т.е. метода) *)PROCEDURE^ (this: Bar) DoAnother (x: INTEGER), NEW;
(* Определения связанных процедур: *)PROCEDURE (VAR this: Foo) DoSomthing (x: INTEGER), NEW;
BEGIN
this.bar.DoAnother(x + 1) (* Вызов еще не определённой, но уже продекларированной процедуры *)END DoSomthing;
PROCEDURE (this: Bar) DoAnother (x: INTEGER), NEW;
BEGIN
this.foo.DoSomthing(x - 1)
END DoAnother;
END Test.
Re[5]: Theory and Techniques of Compiler Construction
Здравствуйте, Aviator, Вы писали:
A>А подробнее можно ?
Ну, знаменитая книжка по генерации кода. Можно купить здесь. Как известно, разработка компиляторов делится на две части: разработка фронтэндов и разработка бэкэндов. Фронтэнд обычно рзрабатывается для языка в единственном числе и компилирует программный код в промежуточное представление, обычно дерево кода программы + таблицы символов и типов. Затем строятся компиляторы этого представления в машинные языки. Язык программирования один, а платформ много. Поэтому и бэкэндов должно быть много, а фронтэнд только один. Процесс построения бэкэнда и называется генерацией код. Это сама по себе сложная наука: анализа потоков данных, оптимизация и т.д. В 80-х годах была построена теория генерации кода и сейчачс активно используется. Поэтому, потребность в специалистах по построению бэкэндов существенно превышает потребность в спецах по фронтэндам. Книжка Мучника — это подробный справочник и учебник по построению бэкэнда, примерно тоже самое, что красный дракон для фронтэндов.
Re[6]: Theory and Techniques of Compiler Construction
Здравствуйте, mefrill, Вы писали:
M>Здравствуйте, Aviator, Вы писали:
A>>А подробнее можно ?
M>Ну, знаменитая книжка по генерации кода. Можно купить здесь. Как известно, разработка компиляторов делится на две части: разработка фронтэндов и разработка бэкэндов. Фронтэнд обычно рзрабатывается для языка в единственном числе и компилирует программный код в промежуточное представление, обычно дерево кода программы + таблицы символов и типов. Затем строятся компиляторы этого представления в машинные языки. Язык программирования один, а платформ много. Поэтому и бэкэндов должно быть много, а фронтэнд только один. Процесс построения бэкэнда и называется генерацией код. Это сама по себе сложная наука: анализа потоков данных, оптимизация и т.д. В 80-х годах была построена теория генерации кода и сейчачс активно используется. Поэтому, потребность в специалистах по построению бэкэндов существенно превышает потребность в спецах по фронтэндам. Книжка Мучника — это подробный справочник и учебник по построению бэкэнда, примерно тоже самое, что красный дракон для фронтэндов.
А в электронном виде книжка существует ?
Re[7]: Theory and Techniques of Compiler Construction
Здравствуйте, Cyberax, Вы писали:
>> C>Вообще-то VC7.1 почти полностью совместим со Стандартом, и диагностика >> C>ошибок в шаблонах — вполне нормальная. Когда я переносил свой проект, >> C>который писался полгода, на GCC — проблем с шаблонам не возникло (а >> их у >> C>меня там мнооого). >> VC7.1 страдает практически такой же болезнью, что и VC6 — он не толком >> не проверяет синтаксис шаблонов до момента их реального использования. >> При написании библиотек это создает проблемы. Даже отсутствие >> банальной ";" в нужном месте — пропускает. GCC и Intel — диагностируют >> нормально.
C>Однако, когда шаблоны все-таки инстанцируются, то происходит полная C>проверка.
C>ЗЫ: я так к это "фиче" привык, что уже забыл про нее. Когда я пишу C>шаблоны, то в cpp всегда ставлю явное их инстанцирование.
Есть еще одна очень большая засада в VC7.1 — не поддерживается полноценный two phase name lookup. Проблема эта, кстати, частично связана и с предыдущей — отутствием синтаксической проверки шаблонов до момента инстанцирования. Это создает видимость нормальной работы на VC7.1, но такой код не будет компилироваться ни GCC, ни Intel C++, ни Comeau. Когда первый раз столкнулся — очень неприятно было.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[8]: Theory and Techniques of Compiler Construction
CrystaX wrote:
> Есть еще одна очень большая засада в VC7.1 — не поддерживается > полноценный two phase name lookup. Проблема эта, кстати, частично > связана и с предыдущей — отутствием синтаксической проверки шаблонов > до момента инстанцирования. Это создает видимость нормальной работы на > VC7.1, но такой код не будет компилироваться ни GCC, ни Intel C++, ни > Comeau. Когда первый раз столкнулся — очень неприятно было.
Мне хватает SFINAE, двухфазный лукап я не использую.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[16]: Theory and Techniques of Compiler Construction
