Так что же надо изучать?

[Bepec]

Они разные, нельзя сравнивать.

А с другой стороны можно сравнить генту и убунту какую нить. Та же фигня выйдет

[Old]

Вообще, как эта задача к Вам попала? Такое дают отсталым, типа "пусть возится, хоть какая-то польза".

Да, это не два цвета сравнивать. Вот где масштаб.
А почему вы не думаете, что парсер BibTex это всего лишь маленькая часть большого проекта?

Я показал что бы я делал склепав грубую бету/альфу за 2-3 часа. Еще день-два на отлов багов (по существу на знакомство со всеми деталями формата) - и все готово. Через неделю уже забыто.

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

А что у Вас? Применяется могучая регулярка + великий буст, но через неск месяцев выясняется что еще есть проблемы. Вы предъявляете довольно сложный (по крайней мере для меня) фрагмент кода который посвящен... выкусыванию примечаний. Затем следует улучшенная версия со встроенным regexp которая успешно разбирается с любыми концами строк. Казалось бы - все, НО ... тут Вы попадаете под очарование spirit'а (что впрочем вполне простительно). Прелести регулярки мгновенно забыты (ах как Вы ветрены), и Вы с энтузиазмом осваиваете spirit. Правда и здесь вылазит бяка с \% - но еще один рывок, и вот оно, счастье, Вы использовали все сделанное умными людьми!

Вы сейчас описали эволюцию ПО.
Возможно все было так: сначала он написал решение "в лоб" (хотя думаю он этот шаг пропустил ), в дальнейшем при попытке добавления нового функционал он осознал не удачность подхода и переписал его на более подходящих и известных ему регулярных выражениях. При очередном расширении функционала (комментарии понадобилось обрабатывать), он увидел возможности спирита и переписал его на нем.
Заметим, что предыдущее решение (регулярки) так же работает, но оценив потенциал спирита он перешел на него, понимая что дальше развивать проект на основе спирита будет проще.
Совершенно адекватное решение: использовать самое удобное из известных на текущий момент. Возможно завтра он посмотрит на ANTLR и, если сочтет, что решение на нем будет эффективней, перепишет все на нем.

Позвольте, а все ли? Ведь есть еще бизон, вот там крутизна! Ну так.....

С чего вы взяли, что там крутизна?

Но нужна ЗАДАЧА порядочная где действительно "по-другому никак".

Самое большое заблуждение.
Любая самая сложная задача (от управления ядерными реакторами и заканчивая управлением полетами) состоит из подзадач, которые в свою очередь делятся на кучу более мелких подзадач, каждая из которой это свой "маленький парсер BibTex". Поэтому, никакой порядочной ЗАДАЧИ вы никогда не дождетесь, в конечном итоге они все будут сводиться к элементарным, грубо говоря: чтение из файла, поиск в коллекции и вывод на экран.
И как вы понимаете, что бы на выходе получилась жизнеспособная и расширяемая система решающая ЗАДАЧУ, все эти маленькие задачи нужно сразу делать хорошо (не пару часов тяп-ляп, а хорошо). Потому что порядочные ЗАДАЧИ живут долго и со временем могут сильно меняться, а гора маленьких решений сделанных тяп-ляп и собранных вместе, не могут меняться, из-за своей непродуманности.
Нужно сразу начинать делать маленькие подзадачи хорошо (с "Тонны typedef, мудреные итераторы и.т.п."), потому что из них будут состоять большие. И любое "маленькое слабое звено" может свести на нет всю "большую систему".

И еще раз: хорошо - это вовсе НЕ означает с std или boost.

[m_ax]

А может они правы?

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

Вообще, как эта задача к Вам попала? Такое дают отсталым, типа "пусть возится, хоть какая-то польза". Если же Вы сами ее нашли/выбрали - тем более удивительно, работа рутинная, перспектив ноль.

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

Я показал что бы я делал склепав грубую бету/альфу за 2-3 часа. Еще день-два на отлов багов (по существу на знакомство со всеми деталями формата) - и все готово. Через неделю уже забыто.

Да-да, мы в курсе, как Вы подходите к делу)

А что у Вас? Применяется могучая регулярка + великий буст, но через неск месяцев выясняется что еще есть проблемы. Вы предъявляете довольно сложный (по крайней мере для меня) фрагмент кода который посвящен... выкусыванию примечаний. Затем следует улучшенная версия со встроенным regexp которая успешно разбирается с любыми концами строк. Казалось бы - все, НО ... тут Вы попадаете под очарование spirit'а (что впрочем вполне простительно). Прелести регулярки мгновенно забыты (ах как Вы ветрены), и Вы с энтузиазмом осваиваете spirit. Правда и здесь вылазит бяка с \% - но еще один рывок, и вот оно, счастье, Вы использовали все сделанное умными людьми! Позвольте, а все ли? Ведь есть еще бизон, вот там крутизна! Ну так.....

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

Тонны typedef, мудреные итераторы и.т.п. - все это может быть оправдано, и даже необходимо. Но нужна ЗАДАЧА порядочная где действительно "по-другому никак". А концептуальность на примере BibTex выглядит глуповато  

Нет, глуповато выдавать такие заявления, не представляя о чём идёт речь..
Вы не знаете о моей задаче - BibTeX - это только малая её часть.
Spirit для этой конкретной задачи подошёл идеально, но Вы, похоже, успокоитесь лишь только тогда, когда я после спирита  перепишу его Вашим "методом в лоб", который даже работал не корректно(

Вобщем, похоже, от всех этих нападок (по другому это не назовёшь) со стороны велосипедистов, не избавиться как от крошек на кровати)


  

[Igors]

Посмотрев на BibTex я увидел что нужны такие ф-ции/методы

- проверить что строка начинается с одного из заданных слов (напр "@book")
- отсечь примечания от % до конца строки (учитывая экранирование \%)
- считать строку от одной кавычки до другой
- считать строку между скобками (учитывая вложенные)
- считать строку от текущей позиции до одного из символов (=},)

Не исключено что я что-то упустил - но "того же плана". Как только этот список оглашен - становится ясно что задачка несложная, самая рядовая. Ну придется чуть повозиться - но никак не более того. Почему это объявляется позорным велосипедом, костылем и халтурой (за которую мне заказчик будет чистить рыло ) - хз. Часто стремление "задействовать тул" приобретает прямо-таки животный характер 

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

[Old]

Кроме секции book там есть и другие, и не все нужно обрабатывать сразу.

[Igors]

Самое большое заблуждение.
Любая самая сложная задача (от управления ядерными реакторами и заканчивая управлением полетами) состоит из подзадач, которые в свою очередь делятся на кучу более мелких подзадач, каждая из которой это свой "маленький парсер BibTex". Поэтому, никакой порядочной ЗАДАЧИ вы никогда не дождетесь, в конечном итоге они все будут сводиться к элементарным, грубо говоря: чтение из файла, поиск в коллекции и вывод на экран.

К сожалению (для меня) - это не так. В основном время тратится на поиск решений. Грубо говоря, алгоритм весит 90% и более. Но его нет. День за днем гугление, чтение диссеров (а лучше тезисов к ним). Здесь я уже согласен с любыми зависимостями, либами, итераторами - лишь бы работало, но нет. Попытка реализовать прочитанную статью (вроде толковую) - выясняется что "гладко было на бумаге". Еще одна - опять ничего  

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

[Old]

К сожалению (для меня) - это не так. В основном время тратится на поиск решений. Грубо говоря, алгоритм весит 90% и более. Но его нет.

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

Именно об этом я писал в том параграфе, на который вы отвечали.

[Igors]

Вот типичная гнусная статейка . Прочитав страничку (аттач) раза 4 единственное что я уяснил - оказывается Колмогоров-то не только учебники писал Пытаясь осмыслить pdf в целом - базовая позиция решение уравнений Навье-Стокса. В моем представлении это 3-х мерный массив (сожрет всю память), эл-ты вектора скоростей которые как-то перетекают в соседние эл-ты и балансируются (это я так представляю). Ну ладно, но как из этого получить картинку??? Фича вроде в том что они нашли метод для создания мелких деталей, но в чем он Мои отчаянные попытки понять пока ни к чему не привели.

Ах, если бы можно было разбить "на ряд мелких задач" - как бы хорошо я их делал!!! Если бы понадобилось я бы выучил весь дуст и поставил ему свечку - нет, 100 свечек!!! Но почему-то у меня ничего не разбивается, и что делать - хз 

[Old]

Ах, если бы можно было разбить "на ряд мелких задач" - как бы хорошо я их делал!!! Если бы понадобилось я бы выучил весь дуст и поставил ему свечку - нет, 100 свечек!!! Но почему-то у меня ничего не разбивается, и что делать - хз 

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

[Igors]

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

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

[Bepec]

В другом месте они. Я даже сомневаюсь что у них есть форум.
Такие вещи на форуме не расскажешь, тут живое общение нужно

PS  точнее расскажешь, но для того чтобы понятно рассказать он как минимум филологом должен быть

[Old]

Не стоит уверять меня в том что Вы ни разу не пробовали сделать сами

Так я и делаю все сам, даже на форумах не спрашиваю.

Да и где они, разбирающиеся? В лучшем случае - гуляют с собачкой, в худшем - суют хобот в дуст  

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

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

В лучшем случае - гуляют с собачкой, в худшем - суют хобот в дуст  

Тут многое зависит от того, как с людьми общаться.

[Bepec]

Любимое занятие магистров - в публикуемой научной работе вырезается одна страница расчётов и заменяется на "Исходя из вышенаписанного".

© Чьи то мемуары.

[Igors]

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

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

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

Ну как же я до этого не додумался Да я бы с удовольствием (и понимаю что знания стоят денег), но так не выходит. Вещь находится "на стыке" - да, научный работник гораздо быстрее разберется в Навье-Стокса, адвекции Мак-Кормака (тоже участвует), но он без понятия что такое UV координаты, procedural noise и.т.п. Нет, конечно он бы разобрался - но и ему надо прилагать усилия (пусть куда меньшие чем мне). Увы - найти желающего разбираться трудно.

[Old]

Увы - найти желающего разбираться трудно.

А кто обещал, что будет легко? Но если не пытаться найти, то он не найдётся точно.

Я как-то делал медицинский софт, так мне математику искало 5 врачей высшей категории.
Они за несколько месяцев перелопатили такой объём, что я им ганарар повысил в двое. Все нашли и главное разобрались, как это считать. Кто сталкивался - знает, как там с математикой в медицинских работах.