Хотите ли Вы в этом разбираться?

[m_ax]

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

Ваша реализация?
А скажите на милость, вот вы ушли гулять с собачкой, а в офисе остались только разносчик кофе и вахтерша баба Маша, как они должны будут исправить ваше решение, если вдруг позвонит заказчик? А?

Ну им простительно) Для них программирование начинается и заканчивается на ХеллоВорлде)
А как известно, в ХеллоВорлде нет ни темплэйтов, ни итераторов, ни бустов, ни других вредных и избыточных непоймикаких концепций)

[Bepec]

Код для сопровождения должен быть простым и самодокументируемым (ну или с комментариями), на программиста любого уровня, знающего C++.
Для вашего кода порог вхождения высок.
Для варианта Igors, который берётся на QString'e реализовать этот протокол, порог вхождения более низкий.

Т.е. ваш код - куча буков для меня на данный момент. Я не могу его поправить и/или изменить.
Код Igors будет для меня более понятен и я смогу его править на свой вкус, имея на руках только знание C++ и описание формата.

Сам сталкивался с таким, когда в одном проекте использовали S11n для сериализации/десереализации. Из-за сложности данных и их связи по 3-5 косвенным идентификаторам обычный его парсер не подходил. Я за день написал свой, по описанию, с нужными мне функциями. И (надеюсь) по сей день работает этот парсер, понятный каждому, кто умеет читать по английски и пользоваться Qt Assistant.
Обобщённость и универсальность это хорошо. Но она неизбежно приводит к усложнению конструкций языка

[Old]

И (надеюсь) по сей день работает этот парсер, понятный каждому, кто умеет читать по английски и пользоваться Qt Assistant.

А почему вы думаете, что Qt знают все. Вы предлагаете человеку, который знает C++ еще и Qt освоить?
А есть много программистов, которые негативно к нему относятся. Да и сам Qt не маленькая библиотечка, тащить его из-за вашего парсера?

Обобщённость и универсальность это хорошо. Но она неизбежно приводит к усложнению конструкций языка

А кто обещал, что будет легко?

[Bepec]

Во 1 поддержка кода в разы легче, когда не нужно специализированное знание чего-то.

Во 2 - Qt не знают всё. Зато надпись QString.replace опознает любой знающий программирование на 3-. А знающий на ровную 3 английский ещё и скажет, что этот метод делает.

В 3 - с помощью Assistant любой - повторюсь - ЛЮБОЙ человек распознает, что делает тот или иной метод. Это достижение троллей и это зверски удобное достижение. Сможете сказать, не солгал, что справка в Assistant по QString непонятнее, чем http://www.boost.org/doc/libs/1_55_0/libs/regex/doc/html/index.html.

В 4 - Qt являлось там стандартом для построения интерфейсов, так что тянуть его не надо было Оно и так имелось.

В 5 - вот именно начинается:
 1 - А вот здесь мы используем трехфазный матерчато-шоколадный генератор.
 2 - Но мы могли бы поставить простую AA батарейку.
 1 - Зато если в будущем, лет через 150, мы будем подключать эту хрень к возможно созданному нейрошлему, нам будет легче!
 2 - Но всё равно устройство то устареет, нужно будет создавать новое!
 1 - Отстать, никто не говорил что будет легко.

[Old]

Во 2 - Qt не знают всё. Зато надпись QString.replace опознает любой знающий программирование на 3-. А знающий на ровную 3 английский ещё и скажет, что этот метод делает.

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

[Bepec]

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

[Old]

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

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

[m_ax]

Дело в том, Верес, что если такой "специалист" слепит этот парсер "по народному", как предлагает igors, то уверяю вас, разобраться и сопровождать  такую кашу будет гораздо сложнее(
И работать это (если и будет) то менее эффективно. И вероятность ошибок в таком коде будет большой.. поскольку любые малые изменения будут затрагивать всю логику..
  

[Bepec]

Если работа ведётся точно по описанию формата - да, проще. Если же формат имеет отклонениями и допущения, то наоборот. Не буду дальше спорить) Развлекайтесь.

[m_ax]

Если работа ведётся точно по описанию формата - да, проще.

Аха, аха.. Уже представляю себе эти "if-else-if-else-switch" простые и универсальные народные решения 

[Igors]

Решение, которое предлагаете Вы, просто захлебнётся(

Да никто не захлебнется если просто и нормально писать, без всяких выкрутасов. Напр

Код

C++ (Qt)
void CBib::ReadFile( CReader & reader )
{
 while (reader.GetNextLine()) {
   switch (GetBibType(reader.mLine)) {
     case type_None:
       continue;
 
     case type_Book:
      mItems.push_back(new CBook());
      mItems.back()->Read(reader);
      break;
    ...
   }
 }
}

Потом я так же распишу CBook::Read, возможно появятся методы ReadTitle и ReadAuthor. Какие проблемы? Кому что непонятно - я объясню. Какие "коленки" и проблемы с сопровождением? Чем мотивирован отказ от нормального рабочего кода в пользу чего-то "утонченного", "изысканного"? Это ж просто извращения!  

(кстатии, символ \% - не является началом комментария, в отличие от просто %)
Вот, для примера, моя реализация парсера, которая легко с этим справляется:

Отам вверху есть GetNextLine, в ней я найду в строке % и проверю предыдущий символ. А может и добавлю метод RemoveComments

[m_ax]

Да никто не захлебнется если просто и нормально писать, без всяких выкрутасов. Напр

Ой ли?
И получится у вас 100500 caseов на каждый тип.. А их там не мало и не факт что что-нибудь нового не добавят.. и придётся вам опять дописывать..
 

Потом я так же распишу CBook::Read, возможно появятся методы ReadTitle и ReadAuthor. Какие проблемы?

Потом Вы также допишите и CArticle::Read, CBooklet::Read, CInbook::Read, CIncollection::Read и так до кучи по всему списку..
А далее, дополнительно к Read нужно будет дописывать не только ReadTitle и ReadAuthor, но и другие не тривиальные аналогичные методы:
ReadNote, ReadAnnote, и т.д. до кучи..

В итоге у вас получается 100500 дополнительных классов и монстрообразные switch конструкции на 100500 строк.. И в случае чего: ищи switщи потом.. или ещё хуже дописывай новоиспечённый тип..

Какие проблемы? Кому что непонятно - я объясню. Какие "коленки" и проблемы с сопровождением? Чем мотивирован отказ от нормального рабочего кода в пользу чего-то "утонченного", "изысканного"?

Да, это действительно смешно) До слёз)

Отам вверху есть GetNextLine, в ней я найду в строке % и проверю предыдущий символ. А может и добавлю метод RemoveComments

А кто Вам сказал, что у вас будет возможность работать с файлом? Например у вас на входе string.. Подождите, я угадаю: напишите ещё один Reader? Парсер ничего не должен знать ни о каких ридерах..

Вобщем, грустно всё это(


   

 

[Old]

Чем мотивирован отказ от нормального рабочего кода в пользу чего-то "утонченного", "изысканного"? Это ж просто извращения!  

А чем мотивирован объектной ориентированный подход по сравнению с процедурным?
Вот вы показали классический процедурный подход, а m_ax - ОО.
А дальше каждый решает сам, какой подход для него ближе и гибче. Тут пока не по чувствуешь - не поймешь.

[Hrundel]

Чем мотивирован отказ от нормального рабочего кода в пользу чего-то "утонченного", "изысканного"? Это ж просто извращения!  

А чем мотивирован объектной ориентированный подход по сравнению с процедурным?
Вот вы показали классический процедурный подход, а m_ax - ОО.
А дальше каждый решает сам, какой подход для него ближе и гибче. Тут пока не по чувствуешь - не поймешь.

Если используются объекты и классы - это уже в любом случае ООП.
Принципы Ноймана никто не отменял, поэтому написание методов не может быть иным, кроме как "классический процедурный подход", как вы это называете.
Процедурное программирование в Qt, в принципе не возможно. Даже при написании консольных приложений.
При этом оба понятия относятся не к подходам, а к парадигмам.
В подходах же, отличают: агентно-ориентированный подход(JADE), компонентно-ориентированное программирование(.NET) и прототипное(JavaScript).
И это подходы не столько к программированию, сколько к структуре языка.

[Bepec]

Я сторонник такого кода, который может понять любой человек с помощью книг и/или помощи. А итераторы, как я убеждаюсь на своём опыте, требуют больше практики и меньше теории