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

спасибо.

их не пишут, их генерируют.
http://en.wikipedia.org/wiki/Comparison_of_parser_generators

вот пример ) http://code.google.com/p/nemerle/source/br...Parser/Parser.n

что-то там много всего) не понял что из этого выбрать?
вот мой синтаксис:

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

A5uKa, не очень понял, чем мне может помочь ваша ссылка...

Добавлено через 4 минуты и 18 секунд
up.

Это сообщение отредактировал(а) boostcoder - 22.11.2010, 13:12

например antlr

посмотрел и понял, сходу не напишешь  
прям целая наука..

Добавлено через 36 секунд
напишу ка я по старинке  

то, что имеет смысл писать на генераторах парсеров "по старинке" не напишешь  

для начала нужна грамматика
потом любой генератор взять и реализовать грамматику на нем

самое сложное как раз грамматика

ну да  
но у меня задача простая.

всем спасибо. вопрос закрыт.

Добавлено через 1 минуту и 22 секунды

а что в моем случае является грамматикой?  

это я должен знать?   

boostcoder, тебе ведь не парсер, а шаблонизатор нужен. потому и уверенность, что "по старинке" будет проще.
а не проще ли будет стандартными средствами языка воспользоваться: контейнерами, шаблонами?
а если эти "метаструктуры" - результат нечеловеческого труда (т.е. генерируются программно), почему бы сразу не генерить С++.

контейнерами и шаблонами из с++ ?


сразу с++ и генерится. но из некоторого метасинтасиса. с++ подобного. с моими наваротами  

да. контейнеры, шаблоны, перегрузка операций - все это в с++ позволяет расширить синтаксис. в известных пределах, конечно, но для многих задач хватает.
неплохие примеры - boost::spirit, boost::signal. интересно сравнить последнюю с сигналами в qt

гм... вы наверное меня не правильно поняли...прочтите тему сначала.


а чего там сравнивать? boost::signals сделаны для людей  

типа

vs

только пример, писал не раздумывая 

baldina, вы точно меня не правильно поняли.

читал

может и не понял. поясните плиз.
как я понимаю, метагенератор нужен для преобразования чего-то в С++
тут два варианта:
1. метакод генерируется автоматически (например, программой-визуальным конструктором). зачем тогда генерить метакод, если можно сразу С++
2. метакод пишется вручную (т.е. полагается, что метакод проще и выразительней). в этом случае предлагаю рассмотреть языковые возможности С++ как альтернативу метакоду

Добавлено через 4 минуты и 12 секунд
(есть еще третий вариант, когда метакод генерится не Вами. тогда странно, что генерилка не комплектуется искомым генератором)

Это сообщение отредактировал(а) baldina - 22.11.2010, 17:17

ага.


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

из того фрагмента что я привел, генерируется 841 строка  
ощущаете разницу?  

ощущаю. 
в boost::spirit грамматика записывается например так:

это не требует комментариев и занимает столько же, сколько та же грамматика для yacc например.
и, конечно, все это разворачивается в до черта строчек кода.
абстракцию и инкапсуляцию для того и придумали, что бы скрывать сложность.
впрочем, спорить не буду. Если Вам проще писать метагенератор - удачи

Добавлено через 2 минуты и 10 секунд
ЗЫ: начните с макросов, тут ваще ниче писать не надо.

baldina, мне знаком спирит. но в том, что пытаюсь сделать я, спирит мне сильно не поможет. посмотрите внимательней на мой пример синтаксиса, и скажите, чем спирит мне поможет, кроме как извлекать лексемы?

Добавлено через 20 секунд
или я чего-то не понимаю...или второе..

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

Лично я для таких целей использую bison. Но у любого генератора парсеров есть некоторый порог вхождения   
Но в любом случае сначала нужна грамматика, MAKCim абсолютно прав.

В вашем случае (для bison'а) она будет выглядеть как то так (это только кусок, не вся грамматика):
Если у вас используется большое подмножество С++ - то проще будет сразу застрелится   

вы сделали вывод 

тут одно из двух, либо Вы правы, либо недостаточно представляете возможности С++   

в результате получится что я напишу еще один спирит  
испорченный телефон...я вам о том, что мне нужно распарсить мой синтаксис чтоб из него сгенерировать с++ код. вы же мне предлагаете написать классы+шаблоны для этого...невъезжаю  

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


ладно..пока общались, написал.
всем спасибо.

Добавлено через 1 минуту и 56 секунд
xvr, отдельное спасибо за помощь.

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

поддерживаю 

Это сообщение отредактировал(а) mes - 22.11.2010, 18:25

2 ТС - а почему бы не взять стандартный для RPC синтакс (IDL) и не изобретать велосипед?

в этом-то и смысл - поизобретать охота 

Добавлено через 2 минуты и 36 секунд

я только ЗА!
но к пониманию того что нужно писать метагенератор я не с фонаря пришел  
давайте пообщаемся на эту тему. наверное я что-то недопонимаю..

тогда опишите задачу - во что (в общем, конечно   ) преобразуется 


и

?

и две конечные точки общения (два простых класса между которыми происходит общение без учета возможной реализации) [как раз на этом мы вроде остановились в прошлой теме]

Это сообщение отредактировал(а) mes - 22.11.2010, 18:59

это сложно..
вам нужно прочесть эту тему: http://forum.vingrad.ru/forum/topic-311688.html
  

и глянуть исходники: http://code.google.com/p/discoly/source/checkout

правда.. сложно это все объяснить..
мы с mes`ом много на эту тему наобщались.

Добавлено через 9 минут и 25 секунд

вот: http://code.google.com/p/discoly/source/br...client/main.cpp
сейчас еще пишу однопользовательский чат. как минималистичный пример.

Добавлено через 9 минут и 46 секунд

странное слово получилось 

Добавлено через 11 минут и 12 секунд
baldina, хотя...mes Вам сможет лучше это все объяснить. если у него есть желание, конечно.

или можно зайти с другой стороны.. 


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

При этом должна остаться возможность исключить класс auth_service  путем замыкания методов auth_agent`a друг на друга..

Добавлено через 2 минуты и 28 секунд

на том моменте, где мы закончили тему.. я сам не до конца понимаю в какую сторону Вы тяните 

Добавлено через 3 минуты и 11 секунд

уже скоро уходить.. гляну чуть позже.. 

Это сообщение отредактировал(а) mes - 22.11.2010, 19:13

присвоить классам/методам ID`ы. зарегать методы по ID`ам.

boostcoder, я ту тему читал. местами. слишком многа букаф))
если я правильно понял, ведется разработка чего-то клиент-серверного, типа RPC: сервер умеет методы, клиент должен их вызывать, причем заранее все методы неизвестны, но вызов на клиенте должен органично вписываться в код.
подобное уже делали, напр. CORBA, COM.

то, что в том топике, мне ясно. и ответы на заданные вопросы тоже (скажу тут, что бы туды-сюды не бегать):

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

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

соображение, которое есть сразу:
допустим есть код

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


Добавлено через 6 минут и 31 секунду
забыл: методы надо с сервером связывать. значит как-то указывать идентификатор, типа

кажись не там я читал. вот оно:

а что если

заголовок один, сервер это или клиент определяется во время компиляции

Добавлено через 41 секунду
мысль забурлила   
пойду полезным займусь, вернусь позже

угу.


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


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


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

Добавлено через 4 минуты

а теперь представьте...5-20 классов(каждого от 5ти методов), и соответственно 5-20 интерфейсов. и еще не забудьте, что все это назначать вам придется в ручную.

вот общий пример.
все просто. ничего лишнего.

вверху реализации классов клиента и сервера.
так же, обратите внимание на:

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

наличие net_servera и net_clienta уже лишнее.. библиотека не должна зависить от того находятся ли два класса в одном приложении или на концах сети.. 


но почему client_side является, как вы говорите, зарезервированным ? допустимее что будет 
client_facet_1, client_facet_2, client_facet_3.. 

сам код пока не смотрел.. 

она и независит. укажите этим классам другие IP/port и поведение будет то же.


это просто ключевое слово. можно назвать по другому. не в этом суть.


ну и?

а если совсем без сокетов ?


ну так я и не к самому названию цепляюсь.. у вас деление на клиент/сервис идет между объектами или приложениями ?

как тогда им общаться?

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

baldina, в контексте данной темы, обсуждение RPC/CORBA выглядит свалившимся с луны.
если есть желание, присоединяйтесь: http://forum.vingrad.ru/forum/topic-311688.html