Здравствуйте, Ka3a4oK, Вы писали:
KK>ИМХО неудачный пример. Если мне придется парсить что-либо, для чего можно составить регулярное вражение или КС-грамматику, я обязательно буду использовать средства автоматизации. Раньше это были bison/lex, сейчас еще хочу попробовать boost::spirit. Даже если мне нужно будет написать парсер для ini-файла, я также буду использовать средства автоматизации. Потому-что: KK> — это просто (Сравните объем кода парсера и объем грамматики.) KK> — это надежно (Во-первых, средства автоматизации обнаруживают все ошибки несоответствия формата. Во-вторых KK>генерируемый код достаточно надежен. Это конечно справедливо для известных инструментов.) KK> — это расширяемо (Расширился формат — добавили несколько прaвил в грамматику.)
KK> Я считаю, кодирование парсеров вручную как раз и есть "ламерство". Данный подход не дает никаких преимуществ.
И что, для того, чтобы распарсить строки с значениями, разделенными запятыми, Вы пойдете изучать boost::spirit с его кучей шаблонов? Неделю ковыряться с ним вместо того, чтобы черкнуть пару вложенных циклов — IMHO верх идиотизма. Можно, конечно, и регулярные выражения использовать, только они будут все же медленнее работать,чем банальная пара циклов. Все эти решения — "из пушки по воробьям стрелять".
KK>И вообще, я не вижу ничего плохого в осмысленном использовании чужого опыта.
Чужой опыт подсказывает, что можно написать sscanf.
В случае с custom INI-форматом — аналогично, зачем изобретать велосипед (кривой скорее всего), если есть:
1) стандартный виндозный формат и API для работы с ним
2) XML и куча парсеров к нему, на любой вкус.
KK> Я считаю, что главное для инженера(кем, по моему мнению, является программист)- это нахождение решения поставленой задачи. Чем лучше инженер, тем найденое решение оптимальней (по разным критериям — качество, стоимость, сроки).
Хороший программист, т.е. тот, который делает работу качественно и в срок, стоит дорого.
Здравствуйте, ArtemGorikov, Вы писали:
AG>В случае с custom INI-форматом — аналогично, зачем изобретать велосипед (кривой скорее всего), если есть: AG>1) стандартный виндозный формат и API для работы с ним AG>2) XML и куча парсеров к нему, на любой вкус.
XML и его парсеры -- это конечно хорошо, только когда из автоматически распарсеного DOM-дерева нужно будет преобразовывать данные в какое-то внутренне представление, то вот здесь главные неприятности и проявляются. Хорошо, если есть инструмент, который поддерживает отображение XML на внутренние типы данных. А вот если такого инструмента нет (как в случае с C++), то приходится писать кучу весьма некрасивого кода. И заниматься вещами, которые могут быть удобно встроены в какой-нибудь велосипед. Вот, например, хранятся в XML целочисленные значения. Получаешь ты их из DOM-а в виде строк, а дальше нужно в двоичное представление перевести. И начинается -- sscanf, istringstream, самописные преобразователи и пр. А добавим еще возможность сохранения значений в XML в разных системах счисления: 0x, 0, 0b -- еще веселее становится.
Имхо, в таких случаях как раз проще взять какой-нибудь велосипедик, который все это за тебя делает. Чем в каждом проектике заниматься подобными преобразованиями.
Disclamer: речь шла о C++, для которого нет стандартных средств отображения структур данных на C++.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А вот если такого инструмента нет (как в случае с C++), то приходится писать кучу весьма некрасивого кода.
Некрасивый код делается некрасивыми программистами. У красивых — все красиво
E>Имхо, в таких случаях как раз проще взять какой-нибудь велосипедик, который все это за тебя делает. Чем в каждом проектике заниматься подобными преобразованиями.
Значит вот что получается:
Если программист не знает что такое парсеры, то он его и не будет делать, так как не знает как.
Если программист не знает что такое парсеры, значит он не будет его писать и делать в нем ошибки.
Если программист не знает что такое парсеры, то он будет искать библиотеку работы с XML написанную людьми знающими что такое парсеры.
Если программист не знает что такое парсеры, то он будет подключать готовую отлаженную библиотеку, чем сократит время разработки.
Вывод:
Программист не знающий что такое парсеры — мечта каждого PM, и должен получать больше чем программист знающий что такое парсеры.
Не пора ли нам забыть, что такое парсеры?
С уважением, Gleb.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
E>>А вот если такого инструмента нет (как в случае с C++), то приходится писать кучу весьма некрасивого кода. GZ>Некрасивый код делается некрасивыми программистами. У красивых — все красиво
E>>Имхо, в таких случаях как раз проще взять какой-нибудь велосипедик, который все это за тебя делает. Чем в каждом проектике заниматься подобными преобразованиями. GZ>Значит вот что получается: GZ>Если программист не знает что такое парсеры, то он его и не будет делать, так как не знает как. GZ>Если программист не знает что такое парсеры, значит он не будет его писать и делать в нем ошибки. GZ>Если программист не знает что такое парсеры, то он будет искать библиотеку работы с XML написанную людьми знающими что такое парсеры. GZ>Если программист не знает что такое парсеры, то он будет подключать готовую отлаженную библиотеку, чем сократит время разработки. GZ>Вывод: GZ>Программист не знающий что такое парсеры — мечта каждого PM, и должен получать больше чем программист знающий что такое парсеры. GZ>Не пора ли нам забыть, что такое парсеры? GZ>
Как будто XML это панацея. Делает фактически только лексический анализ. А про DTD этот программист тоже ничего не знает? То есть, он DTD не напишет? А анализировать XML ручками будет? Получим те же овалы с другого ракурса...
Здравствуйте, all-x, Вы писали:
AX>Как будто XML это панацея. Делает фактически только лексический анализ. А про DTD этот программист тоже ничего не знает? То есть, он DTD не напишет? А анализировать XML ручками будет? Получим те же овалы с другого ракурса...
DTD — это часть спецификации XML. Так что простенький семантический анализ там есть. Всякие XSD и DOM и еще куча, это уже другие спецификации. Посмотри спецификации на w3c.
[[Какая-то ошибка была сначла! Сообщения не трансл.]]
KK>>> Я считаю, кодирование парсеров вручную как раз и есть "ламерство". Данный подход не дает никаких преимуществ.
Правильно.
AG>>И что, для того, чтобы распарсить строки с значениями, разделенными запятыми, Вы пойдете изучать boost::spirit с его кучей шаблонов? Неделю ковыряться с ним вместо того, чтобы черкнуть пару вложенных циклов — IMHO верх идиотизма. Можно, конечно, и регулярные выражения использовать, только они будут все же медленнее работать,чем банальная пара циклов. Все эти решения — "из пушки по воробьям стрелять".
Сначала пара циклов, а потом приложение разрастётся и всё равно придётся готовить "пушку". Уж лучше сразу на максимум расчитывать.
Нет, ну конечно, если приложение перестанет удовлетворять заказчика и за расширением он обратиться к Вам... тогда это даже выгодно.
KK>>>И вообще, я не вижу ничего плохого в осмысленном использовании чужого опыта. AG>>Чужой опыт подсказывает, что можно написать sscanf.
А осмысленный чужой опыт подсказывает, что нельзя.
AG>>В случае с custom INI-форматом — аналогично, зачем изобретать велосипед (кривой скорее всего), если есть: AG>>1) стандартный виндозный формат и API для работы с ним AG>>2) XML и куча парсеров к нему, на любой вкус.
Это то же внешние средства, просто менее мощные.
KK>>> Я считаю, что главное для инженера(кем, по моему мнению, является программист)- это нахождение решения поставленой задачи. Чем лучше инженер, тем найденое решение оптимальней (по разным критериям — качество, стоимость, сроки).
AG>>Хороший программист, т.е. тот, который делает работу качественно и в срок, стоит дорого.
Агитация халтуры и непрофессионализма! Давайте все будет хорошими программистами. Догда работадателям придётся нам зарплату повысить.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, all-x, Вы писали:
AX>>Как будто XML это панацея. Делает фактически только лексический анализ. А про DTD этот программист тоже ничего не знает? То есть, он DTD не напишет? А анализировать XML ручками будет? Получим те же овалы с другого ракурса... GZ>DTD — это часть спецификации XML. Так что простенький семантический анализ там есть. Всякие XSD и DOM и еще куча, это уже другие спецификации. Посмотри спецификации на w3c.
Получается, что вместо парсеров программист должен знать, как писать DTD. Бесплатных пирожных не бывает. А когда не хватит DTD, понадобятся и схемы (XSD) и то, что за ними (Схематрон, например). И не факт, что это легче писать/сопровождать, чем обычный парсер. И ошибок там можно наделать не меньше, а вот легче ли их выловить — я совсем не уверен.
Здравствуйте, FDSC, Вы писали:
FDS>Сначала пара циклов, а потом приложение разрастётся и всё равно придётся готовить "пушку". Уж лучше сразу на максимум расчитывать.
Тогда надо брать другой, более подходящий, инструмент, а не C++.
Здравствуйте, all-x, Вы писали:
AX>Получается, что вместо парсеров программист должен знать, как писать DTD.
Повторюсь. DTD — это часть спецификации XML. По моему там это называется директивами. Если мы не знаем директивы XML, значит мы не знаем XML. XML достаточно строгий формат. AX>Бесплатных пирожных не бывает. А когда не хватит DTD, понадобятся и схемы (XSD) и то, что за ними (Схематрон, например). И не факт, что это легче писать/сопровождать, чем обычный парсер. И ошибок там можно наделать не меньше, а вот легче ли их выловить — я совсем не уверен.
Я уверен. Кроме синтаксиса есть семантика. Конечно, XML сделали по умному и можно дополнитильно семантику прямо парсером проверять. Но это надо реализовывать. И главное обязан знать. В случае использование готовых средств, такие кардинальные знания не нужны. Хочешь, пользуйся директивами, хочешь не пользуйся. Уверяю тебя, большинство пользователей xml о директивах и не догадываются.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, all-x, Вы писали:
AX>>Получается, что вместо парсеров программист должен знать, как писать DTD. GZ>Повторюсь. DTD — это часть спецификации XML. По моему там это называется директивами. Если мы не знаем директивы XML, значит мы не знаем XML. XML достаточно строгий формат.
Интересный аргумент. Только зачем мне возиться с XML тогда, если изучение yacc не более (скорее даже менее) трудоемко?
AX>>Бесплатных пирожных не бывает. А когда не хватит DTD, понадобятся и схемы (XSD) и то, что за ними (Схематрон, например). И не факт, что это легче писать/сопровождать, чем обычный парсер. И ошибок там можно наделать не меньше, а вот легче ли их выловить — я совсем не уверен. GZ>Я уверен. Кроме синтаксиса есть семантика. Конечно, XML сделали по умному и можно дополнитильно семантику прямо парсером проверять. Но это надо реализовывать. И главное обязан знать. В случае использование готовых средств, такие кардинальные знания не нужны. Хочешь, пользуйся директивами, хочешь не пользуйся. Уверяю тебя, большинство пользователей xml о директивах и не догадываются. GZ>С уважением, Gleb.
Зачем наживать себе геморой на задницу, если есть yacc я так и не понял.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, FDSC, Вы писали:
FDS>>Сначала пара циклов, а потом приложение разрастётся и всё равно придётся готовить "пушку". Уж лучше сразу на максимум расчитывать.
WF>Тогда надо брать другой, более подходящий, инструмент, а не C++.
Ну дак, если приложение уже на C++ пишется. Вот более подходящий инструмент и есть уже написанные библиотеки.
AG>>>И что, для того, чтобы распарсить строки с значениями, разделенными запятыми, Вы пойдете изучать boost::spirit с его кучей шаблонов? Неделю ковыряться с ним вместо того, чтобы черкнуть пару вложенных циклов — IMHO верх идиотизма. Можно, конечно, и регулярные выражения использовать, только они будут все же медленнее работать,чем банальная пара циклов. Все эти решения — "из пушки по воробьям стрелять".
FDS>Сначала пара циклов, а потом приложение разрастётся и всё равно придётся готовить "пушку". Уж лучше сразу на максимум расчитывать.
Улыбнуло Действительно, зачем мелочиться, лучше сразу закладываться на максимум — прикрутить лексический анализатор C++ — просто на будущее, если у заказчика требования поменяются.
FDS>Нет, ну конечно, если приложение перестанет удовлетворять заказчика и за расширением он обратиться к Вам... тогда это даже выгодно.
Конечно. А если заняться самодеятельностью и прикручивать фичи, которые никто не просил делать, то можно легко сорвать сроки, и за расширением заказчик обратится уже к кому-то другому, кто делает работу качественно и в срок.
Еще немаловажная вещь — поддержка. Если поддерживать свой код придется тебе, то есть смысл не усложнять себе жизнь, тут действует принцип Оккама.
KK>>>>И вообще, я не вижу ничего плохого в осмысленном использовании чужого опыта. AG>>>Чужой опыт подсказывает, что можно написать sscanf.
FDS>А осмысленный чужой опыт подсказывает, что нельзя.
Это кто такой мыслитель ?
AG>>>В случае с custom INI-форматом — аналогично, зачем изобретать велосипед (кривой скорее всего), если есть: AG>>>1) стандартный виндозный формат и API для работы с ним AG>>>2) XML и куча парсеров к нему, на любой вкус.
FDS>Это то же внешние средства, просто менее мощные.
Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для которого будет написан парсер на boost::spirit?
AG>>>Хороший программист, т.е. тот, который делает работу качественно и в срок, стоит дорого.
FDS>Агитация халтуры и непрофессионализма! Давайте все будет хорошими программистами. Догда работадателям придётся нам зарплату повысить.
Чего агитация? Чтобы считаться хорошим программистом, надо подтвердить это не словом, а делом. А считают себя самыми-самыми супер-пупер программистами все, кто пишет программы. Только не все ими являются в реальности.
ArtemGorikov wrote:
> FDS>Сначала пара циклов, а потом приложение разрастётся и всё равно > придётся готовить "пушку". Уж лучше сразу на максимум расчитывать. > Улыбнуло Действительно, зачем мелочиться, лучше сразу закладываться на > максимум — прикрутить лексический анализатор C++ — просто на будущее, > если у заказчика требования поменяются.
Нужно пркручивать не синтаксический анализатор С++, а _возможность_ его
потом прикрутить. То есть отделить слой чтения конфигов от остальной
программы, тогда тип неонки внутри конфигуратора не будет уже важен.
> FDS>Это то же внешние средства, просто *менее мощные*. > Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для > которого будет написан парсер на boost::spirit?
C>Нужно пркручивать не синтаксический анализатор С++, а _возможность_ его C>потом прикрутить. То есть отделить слой чтения конфигов от остальной C>программы, тогда тип неонки внутри конфигуратора не будет уже важен.
Ну так кто же спорит? Я сказал, что прикручивать boost::spirit для чтения csv-шек глупо. То, что надо прятать реализацию от пользователей объекта, и так ясно.
>> FDS>Это то же внешние средства, просто *менее мощные*. >> Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для >> которого будет написан парсер на boost::spirit?
C>Да, так как он более примитивен
А что хранить-то надо? Для настроек XML подходит как нельзя лучше, незачем тут огород с велосипедами городить. Если как хранилище или БД то причем тогда ini- файл ?
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, Quintanar, Вы писали:
Q>Интересный аргумент. Только зачем мне возиться с XML тогда, если изучение yacc не более (скорее даже менее) трудоемко?
Q>Зачем наживать себе геморой на задницу, если есть yacc я так и не понял.
Во первых не сказал бы что менее. Во вторых кроме знания yacc нужно изобретать язык. А в этом случае можно и хорошенько наглючить. К тому-же, насколько я помню, тот же yacc не очень любит unicode и тем более определение кодировки. Это уже нельзя построить xml парсер.
ArtemGorikov wrote:
> C>Нужно пркручивать не синтаксический анализатор С++, а _возможность_ его > C>потом прикрутить. То есть отделить слой чтения конфигов от остальной > C>программы, тогда тип неонки внутри конфигуратора не будет уже важен. > Ну так кто же спорит? Я сказал, что прикручивать boost::spirit для > чтения csv-шек глупо.
Как сказать, для _меня_ проще будет за пару минут набросать грамматику
на Spirit'е с семантическими действиями на Phoenix'е, которые сразу
формируют нужный массив результатов — так как я уже знаю как этим всем
пользоваться.
Для программиста Васи со второго курса — проще будет налабать "два
цикла". При этом у него, скорее всего, еще и не будет обрабатываться
unescapeing и не будут нормально обрабатываться ошибочные ситуации.
Кстати, корректный парсер для CSV занимает далеко не две строчки: http://www.ioplex.com/~miallen/libmba/dl/src/csv.c
>>> FDS>Это то же внешние средства, просто *менее мощные*. >>> Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для >>> которого будет написан парсер на boost::spirit? > C>Да, так как он более примитивен > А что хранить-то надо? Для настроек XML подходит как нельзя лучше, > незачем тут огород с велосипедами городить. Если как хранилище или БД > то причем тогда ini- файл ?
Ну так вопрос был "что мощнее" Про лучше/хуже я ничего не говорил
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Quintanar, Вы писали:
Q>>Интересный аргумент. Только зачем мне возиться с XML тогда, если изучение yacc не более (скорее даже менее) трудоемко?
Q>>Зачем наживать себе геморой на задницу, если есть yacc я так и не понял. GZ>Во первых не сказал бы что менее. Во вторых кроме знания yacc нужно изобретать язык. А в этом случае можно и хорошенько наглючить.
А в случае XML точно так же надо изобретать схему.
GZ> К тому-же, насколько я помню, тот же yacc не очень любит unicode и тем более определение кодировки. Это уже нельзя построить xml парсер.
Вообще говоря, генератору парсеров и не надо знать по unicode Он работает с потоком токенов.
Но на lex/yacc свет клином не сошелся, инструментов полно, ссылочек подкинуть?
И разбираться, что именно применять, надо в каждом конкретном случае.
Насколько я помню, началось все с обсуждения, как парсить CSV файлы.
Во-первых, XML сразу отдыхает
Во-вторых, если бы знал подходящую проверенную библиотеку для чтения CSV — воспользовался бы ей.
В-третьих, если бы не знал готового решения, может и сделал все на коленке, но постарался бы сделать так,
чтобы в случае надобности можно было бы легко заменить этот кусок на использование тяжелой артиллерии.
C>Как сказать, для _меня_ проще будет за пару минут набросать грамматику C>на Spirit'е с семантическими действиями на Phoenix'е, которые сразу C>формируют нужный массив результатов — так как я уже знаю как этим всем C>пользоваться.
И все же, прикручивать гору кода из-за такой мелочи IMHO не стоит.
C>Для программиста Васи со второго курса — проще будет налабать "два C>цикла". При этом у него, скорее всего, еще и не будет обрабатываться C>unescapeing и не будут нормально обрабатываться ошибочные ситуации.
А кто здесь Вася? Существуют определенные правила поведения в форуме. Так или иначе, не стоит пихать куда ни попадя тяжелую либу только от того, что ты такой крутой. Кому-то не настолько крутому придется это поддерживать.
Думаю, использование spirit не освобождает от ответственности обрабатывать ошибочные ситуации.
>>>> FDS>Это то же внешние средства, просто *менее мощные*. >>>> Правда? А что у нас более мощное, чем XML? Самописный ini-файл, для >>>> которого будет написан парсер на boost::spirit? >> C>Да, так как он более примитивен >> А что хранить-то надо? Для настроек XML подходит как нельзя лучше, >> незачем тут огород с велосипедами городить. Если как хранилище или БД >> то причем тогда ini- файл ?
C>Ну так вопрос был "что мощнее" Про лучше/хуже я ничего не говорил
Вспомнился анекдот про самые поездатые поезда в мире
Здравствуйте, all-x, Вы писали:
AX>А в случае XML точно так же надо изобретать схему.
Не обязательно. Смотря что вы хотите от него.
AX>Вообще говоря, генератору парсеров и не надо знать по unicode Он работает с потоком токенов. AX>Но на lex/yacc свет клином не сошелся, инструментов полно, ссылочек подкинуть?
Не надо. Сам юзаю ANTLR, хотя чаще пишу вручную. Но не для xml.
AX>Вообще, аргументы за и против изобретения собственных языков достаточно хорошо известны. Почитайте хоть Фаулера: http://www.martinfowler.com/articles/languageWorkbench.html#ProsAndConsOfLanguageOrientedProgramming
читал.
AX>И разбираться, что именно применять, надо в каждом конкретном случае.
Безусловно. AX>Насколько я помню, началось все с обсуждения, как парсить CSV файлы.
Нет — обсуждение нужности парсеров. AX>Во-вторых, если бы знал подходящую проверенную библиотеку для чтения CSV — воспользовался бы ей.
Excel AX>В-третьих, если бы не знал готового решения, может и сделал все на коленке, но постарался бы сделать так, AX>чтобы в случае надобности можно было бы легко заменить этот кусок на использование тяжелой артиллерии.
Отвечу также. Почитай хотя бы Фаулера.http://martinfowler.com/articles/designDead.html Делать только то что нужно на данный момент.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, all-x, Вы писали:
AX>>А в случае XML точно так же надо изобретать схему. GZ>Не обязательно. Смотря что вы хотите от него.
Обязательно. Её можно записывать явно или не записывать. Но в программе все равно будут
предположения о том, что может быть в XML — это и есть схема.
AX>>В-третьих, если бы не знал готового решения, может и сделал все на коленке, но постарался бы сделать так, AX>>чтобы в случае надобности можно было бы легко заменить этот кусок на использование тяжелой артиллерии. GZ>Отвечу также. Почитай хотя бы Фаулера.http://martinfowler.com/articles/designDead.html Делать только то что нужно на данный момент.
А вот это фигушки. Я с этим положением XP не согласен.
Не учитывается один важный фактор — сравнительная трудоемкость и производительность вариантов.
При прочих равных я выберу вариант, который легче развивать в предполагаемом направлении.
Лишние усилия тратить не буду. Если известно, что развитие не понадобится, тоже скорее всего не буду делать расширяемый вариант.
Но при прочих равных выберу то, что расширяется.
XML достаточно строгий формат.
?
?
