Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, mefrill, Вы писали:

M>>Здравствуйте, Aviator, Вы писали:

A>>>Часом не DICK GRUNE, CERIEL JACOBS "PARSING TECHNIQUES" ? Если не эта приведите пожалуйста ссылочку Очень интересно было бы ознакомится .

M>>Ага, та самая.

A>К большому сожалению так и не читал эту книжку, хотя давно уже валяется Выс считаете что стоящая книга и если заниматься компиляторами то необходимо прочитать ?

A>PS Кстати по результату пролистыванияне осталось впечатления что книга очень уж простая и сугубо практическая
У меня есть такая. Кому надо — вышлю по запросу в мыло. Объем 1.2 Мб в zip

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Книга Н. Вирта

СГ>Theory and Techniques of Compiler Construction. Addison-Wesley, Reading, April 1996.

СГ>http://www.cs.ucr.edu/~phf/mir/wirth-compiler-1996.pdf
Судя по контенту, довольно поверхностно. К тому же затронуты не самые интересные темы — Мучник, имхо, в качестве референса пополезнее будет. В общем, книжка студентам 1-3 курса.

Здравствуйте, Cyberax, Вы писали:

C>INTERNATIONAL STANDARD ISO/IEC 14882 ?

По этой уже многие пробовали... и не получилось.

Здравствуйте, mefrill, Вы писали:

M>А что там интересного такого?

Ну, трешка похоже просто будет практически идеальным построителем парсеров. А 2.х просто довольно мощьный продукт. А есть там много чего. Декларативное заглядывание вперед (правда становится не актуальным в следующей версии). Декларативное построение АСТ. EBNF. Автоматическое пуравление памятью (ну, это скорее Ява себя проявляет).

В драконах же откровенно говоря каменный век. Куча времени посвящается мало актуальным вещам вроде управления памятью, а про VM вообще ничего нет. ООП даже не затрагивается. Хотя в конце книги приводятся граматики С++ и C#, но они а) даже не рассматриваются, б) они просто не корректны.

Ну, а в этом переводе ее читать вообще очень сложно. Чувствуешь себя недоразвитым идиомто. И это даже если ты знашь про что читаешь.

VladD2 wrote:

> C>INTERNATIONAL STANDARD ISO/IEC 14882 ?
> По этой уже многие пробовали... и не получилось.

У этих четырех парней получилось: http://edg.com/

It supports the C++ language of the ISO/IEC 14882:2003 standard (the
/complete/ language; see our description of language features
<http://edg.com/cpp_ftrs.html&gt;).

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Курилка, Вы писали:

К>Володь, а у тебя её нет в электрическом виде? Огроменное спасибо, если на мыло кинешь

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

К>BTW как в Европу съездил?

Нормально, пойдет.

Здравствуйте, Cyberax, Вы писали:


C>У этих четырех парней получилось: http://edg.com/
C>

C>It supports the C++ language of the ISO/IEC 14882:2003 standard (the
C>/complete/ language; see our description of language features
C><http://edg.com/cpp_ftrs.html&gt;).

Ага. На этом списк удачных попыток заканчивается.
Видимо эти парни имели некоторые потаенные знания почерпнутые из других книг или нажытые по жизни.

Здравствуйте, fplab, Вы писали:

F>У меня есть такая. Кому надо — вышлю по запросу в мыло. Объем 1.2 Мб в zip

Я бы был признателе.

VladD2,

> C>У этих четырех парней получилось: http://edg.com/
> C>

> C>It supports the C++ language of the ISO/IEC 14882:2003 standard (the
> C>/complete/ language; see our description of language features
> C><http://edg.com/cpp_ftrs.html&gt;).
> C>

> Ага. На этом списк удачных попыток заканчивается.
> Видимо эти парни имели некоторые потаенные знания почерпнутые из других книг или нажытые по жизни.

Все проще: для них буквальное следование стандарту было важнее, чем для других.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Здравствуйте, VladD2, Вы писали:

VD>>> ...АНТЛР...

СГ>> АНТЛР — это что?

E>antlr.org

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, fplab, Вы писали:

F>Здравствуйте, Шахтер, Вы писали:

F>>>Здравствуйте, Шахтер, Вы писали:

F>>>У Вирта задача иная — показать КАК можно построить компилятор типичного императивного ЯП. Не более. Что он и делает (кстати, на мой взгляд — превосходно и ясно): берешь книгу, кладешь перед собой и "ваяешь" компилятор прямо по ней

Ш>>Вряд ли по книжке Вирта можно написать компилятор С++, например.

F>В какой-то степени Вы правы — С++ или Java слишком "мудреные" языки Но книга Вирта носит учебный характер и (позволю себе повториться) позволяет научиться строить компилятор ТИПИЧНОГО императивного ЯП.

Точнее сказать -- простого, а не типичного.
Но в тои то и дело, что мы живём в эпоху непростых языков.

F>С++ к таковым, конечно, не относится, а вот обычный С — вполне.

F>P.S. Кстати, в "драконе", сколько мне помнится, тоже ничего нет о реализации объектно-ориентированных языков, классов, интерфейсов, таблицах виртуальных функций или callback-ах. Если я ошибаюсь — буду благодарен за точное указание тех глав, разделов или страниц из "дракона", где эти вопросы освещаются.

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Шахтер, Вы писали:

Ш>>Вряд ли по книжке Вирта можно написать компилятор С++, например.

VD>А по какой книжке можно написать С++-компилятор?

Компиляторы пишут не по книжкам (за исключением самых простых языков).

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Шахтер, Вы писали:

Ш>Эти вопросы там не рассматриваются. Но должен заметить, что как раз они не имеют такого уж принципиального значения при построении компиляторов, поскольку все эти объектно-ориентированные навороты легко ложатся поверх обычных процедурных языков.
Ш>Исключением является только С++ с его шаблонами, обработка которых -- действительно нетривиаьлный предмет.

Шаблоны в C++ — это вообще что-то с чем-то. Попытка вывести невыводимую формулу и поженить несовместимые сущности — макросы и функции. Но несмотря на весь свой негатив, достойной альтернативы шаблонам пока что нет. Generics не считаем — это совершенно другая пара сапог, и эти вещи, можно сказать, ортогональны.
Но хотя бы распарсить шаблоны — задача действительно неприподъемной сложности. Только монстры могут, типа GCC или Comeau, да и то с огрехами.

А все началось с того, что в C++ разрешили использование сущностей вперед их декларации. Вот он, корень зла! Вирт подобные "штучки" считает полной ересью и в чем-то он прав. В самом деле, я могу писать на C++ в традиционном процедурном стиле (Сишном), имея один-единственный огромадный файл и заключив все функции в один класс следующим образом:

class MyMonster
{
   static void foo() { bar(); }
   static void bar() { . . .  } 
   . . .
};

При этом, мне не надо никаких прототипов и/или пре-деклараций. То же самое в Java и C#. А теперь представим, что нам требуется написать парсер и (как это по-русски) symbol resolver для подобного класса бесконечного объема, используя конечный объем памяти (оперативной и дисковой). Для C++, C#, Java подобная задача является в принципе нерешаемой. Для C — решаемой и это — ключевое отличие. Аргумент, что для исходника бесконечного объема требуется и объектник бесконечного объема — не катит, по той простой причине, что транслятор может являться неким сервером, который принимает символы из сокета и посылает результаты в другой сокет. А уж что там в конечном итоге происходит — нам не важно. Так вот, в таких языках, как C++, C#, Java, пока наш гипотетический сервер не засосёт весь класс, он в принципе не может ничего сделать. Ни одного байта сгенерировать не может. А пока он кушает, у него может и рожа треснуть.

А спрашивается, чем в таком случае класс отличается от файла (как единицы трансляции)? Да ни чем! А почему тогда в классе можно использовать имена до их деклараций а в файле нельзя?
В C# или Java ведь тоже запрещено использовать классы вперед их объявлений? Хотя функции внутри классов — можно. Почему? Итак, еще раз, вопрос. Чем в сущности содержимое класса отличается от содержимого файла как единицы трансляции?

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, Шахтер, Вы писали:

Ш>>Эти вопросы там не рассматриваются. Но должен заметить, что как раз они не имеют такого уж принципиального значения при построении компиляторов, поскольку все эти объектно-ориентированные навороты легко ложатся поверх обычных процедурных языков.
Ш>>Исключением является только С++ с его шаблонами, обработка которых -- действительно нетривиаьлный предмет.

MS>Шаблоны в C++ — это вообще что-то с чем-то. Попытка вывести невыводимую формулу и поженить несовместимые сущности — макросы и функции.

Идея шаблонов очень естественна.

MS>Но несмотря на весь свой негатив, достойной альтернативы шаблонам пока что нет. Generics не считаем — это совершенно другая пара сапог, и эти вещи, можно сказать, ортогональны.
MS>Но хотя бы распарсить шаблоны — задача действительно неприподъемной сложности. Только монстры могут, типа GCC или Comeau, да и то с огрехами.

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

MS>А все началось с того, что в C++ разрешили использование сущностей вперед их декларации. Вот он, корень зла! Вирт подобные "штучки" считает полной ересью и в чем-то он прав. В самом деле, я могу писать на C++ в традиционном процедурном стиле (Сишном), имея один-единственный огромадный файл и заключив все функции в один класс следующим образом:
MS>

MS>class MyMonster
MS>{
MS>   static void foo() { bar(); }
MS>   static void bar() { . . .  } 
MS>   . . .
MS>};
MS>

MS>При этом, мне не надо никаких прототипов и/или пре-деклараций. То же самое в Java и C#. А теперь представим, что нам требуется написать парсер и (как это по-русски) symbol resolver для подобного класса бесконечного объема, используя конечный объем памяти (оперативной и дисковой). Для C++, C#, Java подобная задача является в принципе нерешаемой. Для C — решаемой и это — ключевое отличие. Аргумент, что для исходника бесконечного объема требуется и объектник бесконечного объема — не катит, по той простой причине, что транслятор может являться неким сервером, который принимает символы из сокета и посылает результаты в другой сокет. А уж что там в конечном итоге происходит — нам не важно. Так вот, в таких языках, как C++, C#, Java, пока наш гипотетический сервер не засосёт весь класс, он в принципе не может ничего сделать. Ни одного байта сгенерировать не может. А пока он кушает, у него может и рожа треснуть.

MS>А спрашивается, чем в таком случае класс отличается от файла (как единицы трансляции)? Да ни чем! А почему тогда в классе можно использовать имена до их деклараций а в файле нельзя?
MS>В C# или Java ведь тоже запрещено использовать классы вперед их объявлений? Хотя функции внутри классов — можно. Почему? Итак, еще раз, вопрос. Чем в сущности содержимое класса отличается от содержимого файла как единицы трансляции?

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

McSeem2,

> А все началось с того, что в C++ разрешили использование сущностей вперед их декларации. Вот он, корень зла! Вирт подобные "штучки" считает полной ересью и в чем-то он прав.

Гм... Мне лень лезть в спецификацию всевозможных оберонов... Предлагаю поверить в этом Сергею Губанову. Он утверждает

Автор: Сергей Губанов
Дата: 08.06.05

, что для использования класса в Обероне, предварительное объявление не требуется.

> представим, что нам требуется написать парсер и (как это по-русски) symbol resolver для подобного класса бесконечного объема, используя конечный объем памяти (оперативной и дисковой). Для C++, C#, Java подобная задача является в принципе нерешаемой. Для C — решаемой и это — ключевое отличие.

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

> А спрашивается, чем в таком случае класс отличается от файла (как единицы трансляции)? Да ни чем! А почему тогда в классе можно использовать имена до их деклараций а в файле нельзя?

Не совсем так. В C++ определение функции-члена в теле класса (с точки зрения поиска имен) эквивалентно определению ее за пределами класса + добавление квалификатора inline. Соответственно, в определении функций-членов можно использовать имена, введенные где угодно в определении класса, т.к. по определению считается, что компилятор как бы сам выносит определение функции-члена за пределы класса. В объявлении функций-членов, как и в остальных местах в определении класса (исключая определения функций-членов по месту), можно использовать только имена, определенные ранее. Собственно, в C++ возможность определения функций-членов в теле класса — просто упрощенный синтаксис, действительно, перекладывающий часть работы на компилятор. При большом желании можно использовать "полный" синтаксис, облегчая работу компилятору

> В C# или Java ведь тоже запрещено использовать классы вперед их объявлений?

В C# — не запрещено. В Java — не уверен, но, по-моему, тоже можно.

Т.е., имхо, во всех языках все логично: в C++ везде, кроме convenience случая определения функций-членов в теле класса, нужно предварительное объявление сущностей. В C#/Java — не нужно нигде...

Это если мы молчим о шаблонах В случае шаблонов все, действительно, становится намного сложнее, включая подхват имен, определенных после точки использования. А если мы еще и про экспорт в совокупности с ADL вспомним, то, вообще, будет "мама не горюй": поиск имен в определенных случаях заработает между файлами, которые друг в друга не включаются, и даже в анонимных namespaces между разными файлами...

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Все проще: для них буквальное следование стандарту было важнее, чем для других.

Парни, безусловно, монстры! Честно сказать, я не хотел бы заниматься подобными вещами. Это настолько кропотливая и нудная работа, что просто ваащее... И именно поэтому заслуживает пения всяческих дифирамбов. Браво! Лично мне сейчас хватает SVG — это такая ж... там столько противоречий...

(резкий переход к другой теме)
А вообще, мысль такова. Вот придумали C++. И все-таки стараются где-то как-то предоставить адекватные средства. Это очень сложно в силу сложности самого языка. Но GCC, например — уже вполне достойный компилятор с точки зрения стандарта. Да, не полный, но один из наилучших доступных и пригодных на практике. А MS любит перекладывать свою головную боль на пользователей. И делают они это очень умело. Перекладывание проблем на чужие плечи — в этом нет равных MS. Я говорю это не в ругательном смысле, а просто как констатацию. Я даже где-то и сам такой. Не знаю, как лучше выразить свою мысль, но вот аналогия. Apple очень серьезно работает над внешним дизайном приложений. Настолько серьезно, что практически не возникает необходимости менять что-либо после установки. Что я делаю после установки Windows — пол-дня тыкаю во всякие пимпочки, чтобы сделать работоспособным. То же самое — со студиями. Мне ни на фиг не уперлись все эти dockable windows, они только мешаются. А MS говорит — "вот вам, делайте как хотите, а нам вся эта юзабилити пох". Я не против того, чтобы "делайте как хотите", я против того, чтобы дефолтные конфигурации были настолько уродливыми.

Аналогичная фигня — с компиляторами. С шаблонами я могу наколбасить такого, что MS съест и не подавится, в то время, как другой компилятор сразу укажет на банальные ошибки. И будет прав, поскольку я действительно допустил оплошность. Именно поэтому, 99% кода на C++ с шаблонами, который успешно компилируется и работает на MS C++ (и только на нем), требует дополнительного портирования на другие компиляторы. Речь здесь не идет о каких-либо системно-зависимых вещах, просто — некий платформо-независимый код. Ставлю 99 против одного, что код размером более 100K, написанный и отлаженный только на MSC++, не странслируется с первого раза на GCC. И GCC будет прав.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Не совсем так. В C++ определение функции-члена в теле класса (с точки зрения поиска имен) эквивалентно определению ее за пределами класса + добавление квалификатора inline. Соответственно, в определении функций-членов можно использовать имена, введенные где угодно в определении класса, т.к. по определению считается, что компилятор как бы сам выносит определение функции-члена за пределы класса. В объявлении функций-членов, как и в остальных местах в определении класса (исключая определения функций-членов по месту), можно использовать только имена, определенные ранее. Собственно, в C++ возможность определения функций-членов в теле класса — просто упрощенный синтаксис, действительно, перекладывающий часть работы на компилятор. При большом желании можно использовать "полный" синтаксис, облегчая работу компилятору

Да, ты прав. Я несколько сгустил краски. Но вот что действительно плохо в C++ — так это ужасный синтаксис с "::". Вместо того, чтобы писать

void foo::bar()
{
. . .
}

гораздо лучше было бы что-то типа такого:

implement foo
{
   void bar()
   {
      . . .
   }
}

Сразу исчезли бы проблемы с "template template". Синтаксис шаблона функции-члена шаблона класса, имлементированного вне этого класса — это же застрелиться можно иногда. А заставлять писать все внутри класса — вообще маздай. Совешенно невозможно охватить общую картину вглядом. А в Java и C# это возведено в степень догмы.

McSeem2 wrote:

> Аналогичная фигня — с компиляторами. С шаблонами я могу наколбасить
> такого, что MS съест и не подавится, в то время, как другой компилятор
> сразу укажет на банальные ошибки.

Вообще-то VC7.1 почти полностью совместим со Стандартом, и диагностика
ошибок в шаблонах — вполне нормальная. Когда я переносил свой проект,
который писался полгода, на GCC — проблем с шаблонам не возникло (а их у
меня там мнооого).

Вот VC6 — этот действительно с шаблонами не очень дружит.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Шахтер, Вы писали:

VD>>>> ...АНТЛР...

СГ>>> АНТЛР — это что?

E>>antlr.org

Ш>Ты знаешь, я глянул бегло сайт и ничего, кроме достаточно тривиальных вещей не нашел.
Ш>Что там круче дракона? Чисто конкретно, плиз.

Боюсь, что не ко мне вопрос. Сергей просто спросил, что такое ANTLR, я просто дал ссылку на сайт ANTLR.
В общих словах ANTLR -- это генератор нисходящих парсеров для LL(1) грамматик. Плюс, насколько помню, содержит еще и генератор лексического анализатора.
Что там за теория внутрях реализована, меня никогда не интересовало. Просто я наткнулся на него когда несколько лет назад искал объектно-ориентированную замену yacc-у.

Здравствуйте, Cyberax, Вы писали:

C>Вообще-то VC7.1 почти полностью совместим со Стандартом, и диагностика
C>ошибок в шаблонах — вполне нормальная. Когда я переносил свой проект,
C>который писался полгода, на GCC — проблем с шаблонам не возникло (а их у
C>меня там мнооого).

VC7.1 страдает практически такой же болезнью, что и VC6 — он не толком не проверяет синтаксис шаблонов до момента их реального использования. При написании библиотек это создает проблемы. Даже отсутствие банальной ";" в нужном месте — пропускает. GCC и Intel — диагностируют нормально.