Russian Qt Forum

Добрый день

Тема http://www.prog.org.ru/index.php?topic=26958.msg194787#msg194787 (http://www.prog.org.ru/index.php?topic=26958.msg194787#msg194787) безнадежно свалилась в холивар. Насколько я понимаю, утверждается следующее: "настоящий" программист на С++ ОБЯЗАН в совершенстве владеть

- std, boost и template (дополняйте)

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

А не посмотреть ли как делают другие? Возьмем open-source которые доказали свою силу на деле и посмотрим чего там и сколько. Ну судя по исходникам Qt - там все совсем темные :) Ладно, пусть это исключение. Вот мне предстоит задействовать это  http://graphics.pixar.com/opensubdiv/ (http://graphics.pixar.com/opensubdiv/). С чем-то (из того что там используется) я знаком, с чем-то только поверхностно. Но, странное дело, при чтении исходников я ни разу не ощутил "недостаток знаний" :) Я не увидел там ни одной монструозной конструкции которая выбила бы меня из колеи.

Больше примеров (с той и другой стороны) приветствуется.

имхо:
- базовые знания архитектуры железа и ОС для кот. пишешь проги, напр. кэши процессора как работают, что такое переключение контекста, big/little-endian системы и сотни других вещей - вобщем помнить то, о чем учат в ВУЗах
- язык C, язык С++ 2003 и язык C++11 - уже прошло достаточно времени с его появления, грешно не знать что там добавилось и как это юзать.
- STL. Структуры данных и методы/алгоритмы - понимать и уметь объяснить где какая сложность и почему
- паттерны проектирования - маст хэв знать, уметь объяснить что дает и что забирает применение каждого из десятка-полутора паттернов
- boost - вещь объемная, надо знать хотя бы что там есть, чтобы при необходимости вернуться, посмотреть глубже и заюзать, если подходит.
- какие-нибудь системы сборки (CMake, scons, ...)
- компилятор, его опции (напр. чем отличаются уровни оптимизации)
- дебаггинг, профайлинг, статический анализ кода - знать как это делается, какие тулзы лучшие
- doxygen-документирование

Т.е. вы описали курс длиной лет так в 20-25 :) А работать когда?
Я считаю что нужно знать где можно всё это посмотреть :) А применять на практике по надобности.

Поддерживаю мнение о необходимости знания "где посмотреть", а не досконального заучивания.  :)
А джентельменские наборы всплывают из современных вакансий в больше степени я считаю - посмотришь порой, так глаза на лоб лезут, сколько всего знать надо  ;D. Конечно, хорошее знание библиотек это несомненный плюс, но часто это и дикий минус (когда знание это поверхностное, что является частым явлением). Все знакомы с ситуацией, когда на форум приходит новичок и начинает спрашивать, что лучше Qt или C++..  :'( Или, что еще хуже, когда человек имеет какие-то знания о языке и почитав пару статей, что, к примеру, std и boost дают нереальные преимущества в программировании, начинает везде совать увиденные им конструкции, не задумываясь о том, а как на самом деле работает, а как сделать оптимизированней, а как будет в конце концов просто лучше и т.д. Я вот сейчас сижу и спокойно программирую без boost-a к примеру, но знаю, что там есть такие-то и такие-то вещи, которые то-то и то-то могут упросить, но до сих пор не было необходимости даже вчитываться, т.к. обхожусь стандартными средствами самого языка. У меня честно говоря вообще присутствует неприязнь к всевозможным хитроумным библиотекам и постоянная мысль, что любой код должен быть максимально простым и при этом эффективным, не дает мне спать  ;D Наверно на меня повлиял С, в котором все по-спартански аскетично, но я считаю, это хорошее влияние. Каждый раз, когда например надо работать со строкой, я 10 раз думаю, что использовать QString (ну или тот же std::string) или же просто char*. Конечно, многие меня обвинят, что это глупо и надо забыть о char*, раз работаешь с С++, но я уверен с таких простых вещей все и начинается - или ты думаешь, что используешь или просто используешь. Ну, а вообще, мое последнее мнение - настоящий программист должен иметь хорошее алгоритмическое мышление и все. А знать 10 паттернов, 10 систем сборки, 10 библиотек, и еще кучу всего всего - абсолютно бесполезно. Извиняюсь за небольшой оффтоп, но как-то накипело  ;D

конечно, шлифовать мастерство можно и нужно всю жизнь. Но то, что я описал - это, знаючи С++ 2003, без С++11, буста и паттернов, это скорее 1 год, а не 25 лет :)

Если без реального применения знаний, просто затюкать как в школе/институте, то и недели хватит. Затюкал, сдал, забыл. А я под знанием имею в виду глубокое знание. Когда знание есть и подтверждено практическим пользованием. А чтобы попользоваться в реальных задачах тем же бустом - как минимум нужно проектов 80+ поднять и серьёзных.

Очередной бред. Посмотрите на m_ax, он освоил spirit за несколько дней и спокойно применяет его в реальных задачах. :)
А в бусте есть ещё 100500 удобных и простых библиотек, которыми можно пользоваться посмотрев пару примеров.
Сами придумываете страшилки и сами их боитесь. :)

to Old: m_ax освоил 1/4 часть спирита и освоил её % на 20 где то, не более :) Надо видеть весь потенциал. У спирита возможностей дофигища :)
Даже обычный Си++ функционал не используется полностью никем. О некоторых зарезервированных словах многие узнают только когда учебник открывают :D

Это не имеет значения, главное он уже им пользуется и получает от этого профит, потратив на это несколько дней. А дальше можно шлифовать и знания и решения.

Ну так поделитесь со мной, что там у него за возможности.

Он изучил qi.
Остались
Classic. Старая версия Spirit для слоупоков. Продокументирована очень хорошо, но от некоторых хаков и синтаксиса мозги заворачиваются трубочкой.
Karma. Генератор генераторов. Позволяет выводить структуры данных с помощью того же самого синтаксиса, которым они разбираются из текста. Из девелоперского maillist можно сделать вывод, что Karma даже быстрее, чем boost::format.
Lex. Генератор лексических анализаторов.

PS хе хе хе, вы не знали этого? я удивлен.

Вы мне статью с хабра процитировали? :)
Не, вы мне своими словами расскажите, что там за "возможностей дофигища"? Где удобно применять, когда, для чего? Может и правда стоящая вещь? :)

100% бессмысленный комментарий от Old. Old - я с вами не хочу общаться :)

Понимаю. Для вас он бессмысленный потому, что сказать вам нечего. :)
Вы думаете мне хочется опровергать весь этот бред, который вы несете чуть ли не в каждой теме?

Ну вот напр OpenGL. Хочу я его учить или нет - значения не имеет, пока я не выучу и не выпишу все вызовы - работать не будет. А рисовать без OpenGL сейчас несерьезно. GLSL - то же самое, нет GLSL - нет нормального шейдинга. Остается выбор "обертки", но он не так уж велик. Таким же образом жизнь заставляет меня учить и др вещи, напр скоро придется заниматься Objective-C, обойти его никак не удается.

Но вот зачем так рьяно изучать std/boost - хз. Нет, конечно понятие иметь надо, с этим никто не спорит. Но зачем же делать эти вещи "культовыми"? Никаких оснований для этого я лично не видел. Далеко не все open-source юзают буст, а многие даже обходятся без std. Кто знает, может эти ветки просто тупиковые?

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

А кто их так рьяно изучает? :)
Их нужно рьяно изучать только "программистам среднего уровня", остальные ими просто пользуются. :)

Ага, как только нужно два инта из строки достать или финдреплейс на QString сделать, желающих толпа, а как только телефонный номер разобрать или паспортные данные, сразу остаются единицы, а если еще попросить от QString отказаться, то все - нет никого. :)

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

Точно, многие вообще ничего не смогут сделать средствами языка, если у них Qt отобрать с его QString. :)

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

Ну то ладно, эти дешевые понты я переживу. Но какие реальные подтверждения такой точки зрения? Какие же задачи требуют std/boost и только, непременно их (иначе просто хана!). Где же нельзя ограничиться только std контейнерами - а то и вместо их использовать Qt аналоги? (напр QList частенько приятнее)

Нет, просто вам хочется в это верить..


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

А потом на форуме появляются темы, вроде этой.. с непонятными претензиями к бусту, стл и всему тому, что выходит за рамки их обыденности(
   

Хых, спесь лезет :)

Конечно лезете, на большее то вы не способны, если по существу ответить нечего..
Тут грустный смайлик ставить надо  :'(

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

Велосипеды - главный двигатель прогресса, если кто не знал  ;D

Боже ж мой.. Теперь, как всегда, пошли необоснованные обвинения.. Кто же вам тут нагрубил то, бедненькому, мм?

 

Вики
Примеры более грубых нарушений этики

• Злые насмешки и провокации.
• Грубость в адрес другого участника, нападки на его личность, включая расовые, национальные, религиозные и сексуальные ярлыки и намёки.
• Вандализм на личных страницах участников.
• Намеренное искажение имени и (или) ника участника.
• Неприличные предложения и намёки.

Нарушение принципов этичного поведения происходит, например, когда участнику, только что создавшему новую статью, говорят: «Если вы уже собрались написать ненужную статью, может, хотя бы уберёте из неё орфографические ошибки?». Достаточно просто ответить: «Не лезьте не в своё дело» — и одно-единственное невежливое замечание приводит к конфликту.

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

Могу ещё процитировать :D

PS конкретизирую - второй пункт списка :) В просторечии "переход на личности" :) Меня всегда веселит когда люди не умеют признавать свои ошибки ^.^

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

:) Прям как в фильмах :) Читать не читают, зато пишут :) Ну да хватит оффтопить :D

Это забавно слышать от человека у которого 90% постов оффтоп. :)

Я думаю, апогеем всего этого.. хм.. будет демонстративное занесение нас в его ЧОрный Список) И будем мы там вместе со Sparkом куковать)
А Верес, с победоносным выражением лица:
-Я программист, я программист ха ха ха :D
-Вот справка из вики, вот справка из вики  :D
-аляхер-маляхер, аляхер-маляхер.. ха ха ха  :D

...
  
Детский сад, короче)

Cruel... cruel programmers...

А может они правы? :) Давайте посмотрим на примере Вашей эскапады с BibTex.

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

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

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

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

А можно linux считать велосипедом по отношению к Windows?  ;D

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

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

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

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

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

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

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

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

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

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

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

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

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

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


  

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

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

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

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

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

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

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

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

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

Вот типичная гнусная статейка (http://www.google.com.ua/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&sqi=2&ved=0CCMQFjAB&url=http%3A%2F%2Fwww.cs.cornell.edu%2F~tedkim%2Fwturb%2Fwavelet_turbulence.pdf&ei=hACYU8bpG6u7ygOD6IC4Aw&usg=AFQjCNG4nLa0c5cb-dqOUyqll7-X_Tz9wQ&sig2=5WEg3Yt5I1bUZWdl4V7ACw&bvm=bv.68693194,d.bGQ&cad=rja) . Прочитав страничку (аттач) раза 4 единственное что я уяснил - оказывается Колмогоров-то не только учебники писал :) Пытаясь осмыслить pdf в целом - базовая позиция решение уравнений Навье-Стокса. В моем представлении это 3-х мерный массив (сожрет всю память), эл-ты вектора скоростей которые как-то перетекают в соседние эл-ты и балансируются (это я так представляю). Ну ладно, но как из этого получить картинку??? Фича вроде в том что они нашли метод для создания мелких деталей, но в чем он ??? Мои отчаянные попытки понять пока ни к чему не привели.

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

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

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

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

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

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

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

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

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

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

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

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

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

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