Здравствуйте, Кодт, Вы писали:

__>>Фортран (насколько я знаю, общаясь с людьми, которые до сих пор предпочитают реализовывать алгоритмы на нем) живет за счет того, что несмотря на то, что его BNF грамматика была выведена тык-скыть "апостериори", дерево разбора проги на Фортране цитирую "лучше оптимизируется, чем С". Я — не могу понять (если честно) как так может быть. Но (в качестве косвенного доказательства) — Ватком до последнего развивал как С/С++, так и Фортран.

К>Мне кажется, так исторически сложилось.

Не, даже
Ща поясню, откуда такая реакция (легкий оффтоп). Работал я в одной немецкой конторе. Ну и их манагеры регулярно, но нечасто (1 — 2 в год) наезжали к нам по своим манагерским делам (с новыми веяниями в конторе ознакомить, привнести "роскошь человеческого общения", этц.). И заканчивалась их программа пребывания "лёхким" таким банкетом перед отъездом. Поскольку с нашей стороны народу было немного (никогда не работало больше 10 человек) — участвовали все. И вот в один из приездов, на предотъездных посиделках, когда все еще себя пьяными (ОК, выпившими ) не считают, но языковый барьер уже истончился донельзя, немец спросил чегой-то (конкретно что, я уже и не помню — несколько лет прошло) о нашем быте. Ну тут и прозвучало "Так исторически сложилось" (Историю КПСС в той команде сдавало абсолютное большинство). И чем все это кончилось ? Когда нам перекинули очередную либу на сопровождение (а потом еще одну, потом еще одну...) 90% ответов на наши запросы на предмет того, почему и зачем _это_ сделано так тупо, а тут — зачем выполняются лишние телодвижения — письма с ответами начинались с "due some historical reasons..." И нередко на этом и заканчивались.

К>На Фортране писали (и пишут) математику, в том числе для суперкомпьютеров, поэтому вопросы глубокой оптимизации в фортран-компиляторах очень тщательно проработаны.
К>Ну и сам язык попроще — меньше шансов сделать программу неоптимизируемой.

Ну да. Завернуть "тройной боцманский загиб" на фортране, в отличие от С не получится Есть здесь спецы по Фортрану ? Мне что-то о декларации COMMON рассказывали и как она в этом деле (оптимизации) может помочь. Речь идет о Фортран-77.

ЗЫ. Сам я в Фортране не силен. Хотя и писал на нем лабораторные, но это было >15 лет назад. Забыл все.

Здравствуйте, Alexey Chen, Вы писали:

AC>Филосовский вопрос.... Почему люди любят, просто обожают, решения в которых без бутылки водки не разберешся?

AC>Я что-то не понимаю?

AC>Как пример. Кто-то мне может сказать, почему BOOST — этот очень непрозрачный запутаный код, который в случае первой же проблемы сожрет кучу проектоного времени, преподноситься как светлое будущее всех C++ программеров? Почему Маерс и Александреску считаются символами истинной веры в правильный код, когда они только популизаторы конкреных и весьма не новых подходв. Я уже задолбался получать советы — 'почитай Маерса'. Почему все, чего нет в 'библии' — ламеризм?

AC>Как связаны вещи перечисленные в сабже?

Ой долго мне всё читать что тут понаписывали. Так что если повторю кого-то то сильно ногами не бейте.
Вы видели когда нибудь универсальный атомный отвертку, кофеварку и бритвенный станок в одном лице? Не видели, а я видел это С++. Да на нём можно делать всё, да он проектировался как "general-purpose programming language" Copyright Bjarn Straustroup. Но вот скажите честно, нужен ли такой универсальный девайс если можно взять отдельно отвёртку, отдельно кофеварку и отдельно бритвенный станок. Язык должен быть заточен на конкретный круг задач, семантика языка должна быть простой и понятной, в больших проектах и так хватает головоломок и нетривиальных технических задач, чтобы терять время на то чтобы разбираться с тонкостями семантики. Не нужно имитировать на С++ фичи которых у него нет, нужно программить на языке который эти фичи поддерживает а потом всё это богатство связывать вместе чем нибудь скриптовым, благо выбор большой python tcl и проч. Нет серебрянной пули и С++ — не серебрянная пуля. Он лишь инструмент, который по моему начинает забредать дааалеко не туда. Это слишком круто когда один файл умудряющийся использовать всего один аспект архисложного шаблона компилируется несколько секунд, а если таких файлов тысяча?

P.S. Я люблю С++ но мне больно видеть как он становиться всё менее прозрачным и всё более сложным.

Привет.

AC>Ссылочку в стандарте пожалуйста. Или ты про доку к конкретному STL'ю? Дык мы вроде говорим о том, что оно везде одинаково работает
AC>Вот в пункте 23.1 говорится, что, вообще говоря, типа должна быть константная. Дальше внимательно смотрим, горячо нами любимый, STLport и видим что она, блин, линейная. Странно да?

Там же описана семантика его работы — end()-begin(). У листа итераторы такие, что ровно linear и будет.
Честно говоря, меня при взгляде на сноски после этой таблицы сильно удивил бардачок...
Я так понял, что они там на каком-то крутом английском языке написали, что size() должен подсчитываться при
вставке, удалении и прочих подобных операциях. Медитировал над этим абзацем минут десять, да и то не уверен, что правильно понял.
Я при работе с STL использую документацию от SGI и книгу Мейерса, а стандарт — для контроля, в сумме корректно получается.
Конечно стандарт есть стандарт, но он там многие мометны (типа этого) весьма мутно расписаны...

AC>>>Про std::string на нескольких процессорах вспоминать будем?
VVB>>А вот это конкретный косяк реализации строк в конкретной реализации STL. Наоптимизировались, copy-on-write устроили.
VVB>>Мало того, с вероятностью близкой к единице везде, где есть такие оптимизации, будут проблемы (и с производительностью тоже).
AC>И тоже везде одинако работает?

Что одинаково? Я как раз имел в виду, что такая оптимизация будет много где некорректно работать.

AC>Я про то что C++ — это совсем не стандарт, а набор рекомендаций, и STL не везде и не всегда одинаково работает.
AC>Это не значит что его не надо использовать, это значит, что не надо повторять на каждом углу миф о его абсолютной портабельности.

Именно, что в стандарте C++, что в описании STL от SGI (на которое ссылается документация по STLPort), многие
вещи оставлены на усмотрение разработчиков реализации... Это касается и компиляторов, кстати.
С этим просто надо жить...

AC>>>Хм, задача, нужно переключать контексты при нотификации кондишина, не как получится, а по порядку. Решение?
AC>>>Не забываем что хип в многопоточноп коде — просад производительноси в 5-10 раз.
AC>>>А потом думаем, что лучше, сделать свой список и держать ноду в стеке функции ожидания, или юзать std::list, но через задний проход.
VVB>>Тут надо не забывать, что:
VVB>>1) не всегда просад есть
VVB>>2) даже когда он есть, он может вообще не влиять ни на что
VVB>>Если же вилы — то оптимизируем. Причем тут еще думать надо, лечить ли следствие или причину.

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

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

VVB>>Vitaly Belekhov
AC>Да Виталя, я конечно понимаю, что в твоих глазах я последний ламер, но задачу ты явно не понял.

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

PS: Мой принцип — "все уже давно сделано". Просто я предпочитаю использовать то, что есть, до тех пор, пока оно подходит. Поиск оптимального решения с учетом многих факторов (цены разработки и сопровождения в том числе) — не очень простая задача...

--
Vitaly Belekhov

Здравствуйте, VVB16, Вы писали:

VVB>Там же описана семантика его работы — end()-begin(). У листа итераторы такие, что ровно linear и будет.
VVB>Честно говоря, меня при взгляде на сноски после этой таблицы сильно удивил бардачок...
VVB>Я так понял, что они там на каком-то крутом английском языке написали, что size() должен подсчитываться при
VVB>вставке, удалении и прочих подобных операциях. Медитировал над этим абзацем минут десять, да и то не уверен, что правильно понял.
Я вот тоже долго медитировал.

VVB>>>Мало того, с вероятностью близкой к единице везде, где есть такие оптимизации, будут проблемы (и с производительностью тоже).
AC>>И тоже везде одинако работает?
VVB>Что одинаково? Я как раз имел в виду, что такая оптимизация будет много где некорректно работать.
Сорри, это я как-то уже на автомате, адрналин в голову стукнул

VVB>Именно, что в стандарте C++, что в описании STL от SGI (на которое ссылается документация по STLPort), многие
VVB>вещи оставлены на усмотрение разработчиков реализации... Это касается и компиляторов, кстати.
VVB>С этим просто надо жить...
Но таки, ситуация с компатибильностью, одна из причин, почему своё писать ингода приходится, или SGISTL за собой таскать и цкплять заместо родного для компилера STL'я (что не всегда возможно). С другой стороны топик-то вообще про BOOST был, и про Modern C++ как путь в светлое будущее.

VVB>Просто в твоих постах я увидел приверженность принципу "я знаю, как сделать лучше".
VVB>Видимо переусердствовал ты слегка, поэтому такое впечатление и сложилось.
Да задели меня сильно.... щас вроде уже упокоился Я не знаю, как правильно/лучше, но, ИМХО, у любой задачи есть, как минимум, два решения. И меня удивляет, когда мне кто-то говорит — делай так и только так Это не про тебя — это вообще. Бывает иногда такое.

Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, VVB16, Вы писали:

VVB>>Просто в твоих постах я увидел приверженность принципу "я знаю, как сделать лучше".
VVB>>Видимо переусердствовал ты слегка, поэтому такое впечатление и сложилось.
AC>Да задели меня сильно.... щас вроде уже упокоился Я не знаю, как правильно/лучше, но, ИМХО, у любой задачи есть, как минимум, два решения. И меня удивляет, когда мне кто-то говорит — делай так и только так Это не про тебя — это вообще. Бывает иногда такое.

Кто конкретно, где и когда такое говорит-то?
Имхо, плох тот программер, который считает, что есть только 1 способ решения задачи и никак иначе. Ибо способов обычно — куча, только вот задача — выбрать наиболее приемлемый по всем значимым критериям (сейчас и с заделом на будущее)

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

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Alexey Chen, Вы писали:

AC>>Здравствуйте, VVB16, Вы писали:

VVB>>>Просто в твоих постах я увидел приверженность принципу "я знаю, как сделать лучше".
VVB>>>Видимо переусердствовал ты слегка, поэтому такое впечатление и сложилось.
AC>>Да задели меня сильно.... щас вроде уже упокоился Я не знаю, как правильно/лучше, но, ИМХО, у любой задачи есть, как минимум, два решения. И меня удивляет, когда мне кто-то говорит — делай так и только так Это не про тебя — это вообще. Бывает иногда такое.

К>Кто конкретно, где и когда такое говорит-то?
К>Имхо, плох тот программер, который считает, что есть только 1 способ решения задачи и никак иначе. Ибо способов обычно — куча, только вот задача — выбрать наиболее приемлемый по всем значимым критериям (сейчас и с заделом на будущее)

К>З.Ы. Такое ощущение, что ты на весь мир обиделся, но задел-то тебя в любом случае кто-то конкретный, зачем же так обобщать-то "с плеча"?

Могу пояснить свою позицию. Я наблюдаю тенденцию бездумного использования решений, при котором человек идет по граблям, шаг влево шаг в право и удар полбу, но спасает копи-паст и похожесть ситуации для которой был приведен оригинал. Ошибки то не только в самопальных контейнерах и алгоритмах бывают, но и в коде их использующем, а С++ язык суьрёзный, он ошибок не прощает. И чем сложнее те либы которые человек использует, тем жёстче его ударит, если он гденить очепятается и порушит память.

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

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

Здравствуйте, Alexey Chen, Вы писали:

AC>Могу пояснить свою позицию. Я наблюдаю тенденцию бездумного использования решений, при котором человек идет по граблям, шаг влево шаг в право и удар полбу, но спасает копи-паст и похожесть ситуации для которой был приведен оригинал. Ошибки то не только в самопальных контейнерах и алгоритмах бывают, но и в коде их использующем, а С++ язык суьрёзный, он ошибок не прощает. И чем сложнее те либы которые человек использует, тем жёстче его ударит, если он гденить очепятается и порушит память.

Логично. Обычно такое при выборе мало подходящего инструмента бывает... или его неправильном использовании, как ты и написал. Но если человек по документации и литературе не может правильно использовать что-то, то я уверен, что и сам он такое напишет, что все вздрогнут.
С другой стороны — представь, что надо было бы сделать самим, чтобы реализовать что-то, что потребовало привлечения
сложной библиотеки...

AC>Я вот одно время, прмерно раз-два в неделю помогал 'опытным' девелоперам вылавливать ошибки в коде. Ошибки не в бусте и не в STL, а в мозгах, но чтобы их выловить мне приходиться ореинтироваться в том же бусте, хотя мне самому он даром не нужен, и разбирать дикие STL бинды После этого, я некоторые варианты решений вообще не обьясняю и даже не упоминаю, потому как копи-паст не пройдет Печально это.

А теперь представь, что ты бы вылавливал ошибки в самопальном коде девелоперов с ошибками в мозгах.
Сдается мне, что тогда ты бы может наоборот их пинками на boost и stl загонял.

AC>Собственно меня интересовало отношение к ситуации других людей. Но все почему-то вылилось в 'STL-есть рулез'.
AC>Наверное слишком нервно писал

Я свое отношение написал в предыдущем абзаце.
У меня как раз бывло много случаев с разбирательством в самопальных решениях, так что я вывод сделал — проще людей stl, boost, you-name-it научить, чем постоянно в уникальных и неповторимых решениях разбираться... А не дай бог еще команду такую расширять или там ротацию кадров провести — все, труба. Да и членомерство при использовании готовых решений сводится к минимуму — тогда команда из "мачо" (привет Платову ) и "почти мачо" может работать. Надо только при выборе инструментов пообсуждать, шириной пальцев помериться, а не постоянно.

--
Vitaly Belekhov

Здравствуйте, VVB16, Вы писали:

VVB>А теперь представь, что ты бы вылавливал ошибки в самопальном коде девелоперов с ошибками в мозгах.
VVB>Сдается мне, что тогда ты бы может наоборот их пинками на boost и stl загонял.

Дык я о том, что или-или — это подход сомнительный, но очень горячо отстаиваемый. Я говорил про _и_.
И еще я говорил про BOOST, например. Есть к примеру в бусте замечательный format. У меня тоже есть, но не такой сложный, более быстрый и четко соответствующий _мом_ требованиям и не делающий того что мне _не_ нужно. Вопрос, прав ли я, что использую свой, а не из BOOST'а?

Как лично ты отнесешся увидев, что в коде используется класс рамером в ~200 строк, а не 5 фалов плюс ядро буста, для которого вообще-то, по уму, все дцать мегов за собой тащить надо? Или используется не STL строка, для которой многие вещи неоднозачны или не определены, а своя. Причем совместно с STL алгоритмами, векторами, мапами... Интересно, например, твое мнение на эту тему.

Здравствуйте, Alexey Chen, Вы писали:

AC>А STL, норамльное стандартное средство. Я прикрасно понимаю, что значит стандартное, как и что именно я делаю когда я пишу его конструкции. Но вот часто стал замечать, как некоторые мои колеги/знакомые пользуют его на автомате как прочитали или где-то увидили. С одной стороны это хорошо, пишут однообразный (однотипный/шаблонный) хотя и не всегда понятный код, с другой плохо — они не задумываются что пишут и почему именно так. Как автоматы.

А вот за это — мой тебе отдельный респект.

Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, VVB16, Вы писали:

VVB>>А теперь представь, что ты бы вылавливал ошибки в самопальном коде девелоперов с ошибками в мозгах. ;)
VVB>>Сдается мне, что тогда ты бы может наоборот их пинками на boost и stl загонял. :)

AC>Дык я о том, что или-или — это подход сомнительный, но очень горячо отстаиваемый. Я говорил про _и_.

если често, совершенно не было понятно, что ты говорил про _и_. И даже про _или_.
Насколько я понимаю, многие (в том числе и я) услышали _не_.

AC>И еще я говорил про BOOST, например. Есть к примеру в бусте замечательный format. У меня тоже есть, но не такой сложный, более быстрый и четко соответствующий _мом_ требованиям и не делающий того что мне _не_ нужно. Вопрос, прав ли я, что использую свой, а не из BOOST'а?

ничего не могу сказать про format — всегда пользовался printf.
но вот практически всю начинку boost/utility я лично считаю исключительно удобной для использования и абсолютно прозрачной для понимания.
Думаю, ты со мной согласишься.

а по поводу преимуществ твоего формата перед бустовским: вполне допускаю, что они есть, вопрос, стоят ли они того, чтобы его предпочесть бустовскому?
Если да и ты можешь это аргументировать — все в порядке.

AC>Как лично ты отнесешся увидев, что в коде используется класс рамером в ~200 строк, а не 5 фалов плюс ядро буста, для которого вообще-то, по уму, все дцать мегов за собой тащить надо? Или используется не STL строка, для которой многие вещи неоднозачны или не определены, а своя. Причем совместно с STL алгоритмами, векторами, мапами... Интересно, например, твое мнение на эту тему.

Если есть достаточное обоснование — почему нет?
Просто обычное в таких случаях обоснования "потому что boost", "потому что STL", "потому что шаблоны", "потому что исключения" вряд ли можно рассматривать как серьезные, а, к сожалению, именно такую аргументацию очень часто приходится слышать.

Ну и вопрос надежности. Все-таки 200 строк — это достаточно большой класс.
Достаточно ли он оттестирован? Есть ли к нему юнит-тесты?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

JJ>если често, совершенно не было понятно, что ты говорил про _и_. И даже про _или_.
J>Насколько я понимаю, многие (в том числе и я) услышали _не_.
Вполне возможно. Я могу иногда пропускать какие-то мысли, на автомате считая, что и так ясно

AC>>И еще я говорил про BOOST, например. Есть к примеру в бусте замечательный format. У меня тоже есть, но не такой сложный, более быстрый и четко соответствующий _мом_ требованиям и не делающий того что мне _не_ нужно. Вопрос, прав ли я, что использую свой, а не из BOOST'а?

J>но вот практически всю начинку boost/utility я лично считаю исключительно удобной для использования и абсолютно прозрачной для понимания.
J>Думаю, ты со мной согласишься.
Вобщем да, но у меня необходимости в нем не возникает. Когда я говорю про BOOST я имею в виду: format, function, signal ...

AC>>Как лично ты отнесешся увидев, что в коде используется класс рамером в ~200 строк, а не 5 фалов плюс ядро буста, для которого вообще-то, по уму, все дцать мегов за собой тащить надо? Или используется не STL строка, для которой многие вещи неоднозачны или не определены, а своя. Причем совместно с STL алгоритмами, векторами, мапами... Интересно, например, твое мнение на эту тему.

J>Если есть достаточное обоснование — почему нет?
Почему нет что?

J>Просто обычное в таких случаях обоснования "потому что boost", "потому что STL", "потому что шаблоны", "потому что исключения" вряд ли можно рассматривать как серьезные, а, к сожалению, именно такую аргументацию очень часто приходится слышать.
Тоесть априори это плохо? Пока у меня нет аргументации почему вместо BOOST/STL я использую X, я как профессионал должен использовать BOOST? Например, потому, что синтаксис используемый в X мне нравится больше. (Где X другая утильная библиотека, например MFC, QT, что-то что давно и успешно используется в проектах нашей компании). Чем не аргумент?

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

Хотя, 'потому что буст' — это ведь тоже аргумент. Это ж какого монстра со своими исходниками таскать надо

Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, jazzer, Вы писали:

J>>Просто обычное в таких случаях обоснования "потому что boost", "потому что STL", "потому что шаблоны", "потому что исключения" вряд ли можно рассматривать как серьезные, а, к сожалению, именно такую аргументацию очень часто приходится слышать.
AC>Тоесть априори это плохо? Пока у меня нет аргументации почему вместо BOOST/STL я использую X, я как профессионал должен использовать BOOST? Например, потому, что синтаксис используемый в X мне нравится больше. (Где X другая утильная библиотека, например MFC, QT, что-то что давно и успешно используется в проектах нашей компании). Чем не аргумент?

Я не ослышался, или MFC нонче лучше STL считается?

Здравствуйте, Курилка, Вы писали:

К>Я не ослышался, или MFC нонче лучше STL считается?
Я разве сказал лучше? Я привел вполне себе аргумент.

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

Здравствуйте, jazzer, Вы писали:

J>ничего не могу сказать про format — всегда пользовался printf.
....
J>Ну и вопрос надежности. Все-таки 200 строк — это достаточно большой класс.
J>Достаточно ли он оттестирован? Есть ли к нему юнит-тесты?

Мне, пока я шёл до дому, пришла в голову очень интересная мысль.
Пока я использую printf, мой код будет считаться надежным, а как только я попробую использовать свой форматтер, сразу же станет ненадежным, и я буду достоен всяческого порицания, что не пользую аналогичное решение из BOOST'а.

Это просто мысля.

Здравствуйте, Alexey Chen, Вы писали:

AC>Мне, пока я шёл до дому, пришла в голову очень интересная мысль.
AC>Пока я использую printf, мой код будет считаться надежным, а как только я попробую использовать свой форматтер, сразу же станет ненадежным, и я буду достоен всяческого порицания, что не пользую аналогичное решение из BOOST'а.

AC>Это просто мысля.
Совершенно верно. Дело в том, что если ты написал свой код, и он работает, и заказчик доволен, то тебя могут упрекнуть только в том, что ты создал потенциальные сложности с ним твоим последователям. Ну, предположим что ты все откомментировал, написал референсе, гайд, и даже туториал с самплами на каждый дурацкий метод. Уверяю тебя — самый злой и недалекий манагер от тебя отлезет.

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

Вся практика менеджмента разработкой софта гласит: "Не изобретай". Каждое отступление от стандарта должно быть обосновано. Творчество — очень трудный, дорогостоящий, а главное — вредный процесс.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Alexey Chen, Вы писали:

AC>>Мне, пока я шёл до дому, пришла в голову очень интересная мысль.
AC>>Пока я использую printf, мой код будет считаться надежным, а как только я попробую использовать свой форматтер, сразу же станет ненадежным, и я буду достоен всяческого порицания, что не пользую аналогичное решение из BOOST'а.

AC>>Это просто мысля.

S>Вся практика менеджмента разработкой софта гласит: "Не изобретай". Каждое отступление от стандарта должно быть обосновано. Творчество — очень трудный, дорогостоящий, а главное — вредный процесс.

Я не про это

Я про то, что когда потенциальные ошибки размазаны по коду (аргументы printf) это нормально, а когда они потенциально замыкаются на одно место (format) это плохо, но когда они замыкаются на непонятный, сопровождаемый кем то третим, код, это опять нормально, но уже потому, что есть чем прикрыть задницу. А получается именно так. Ошибки-то от использования чужого и более сложного решения не изчезают, они просто загоняются еще глубже и становяться более хитрыми и трудноуловимыми.

На тему не изобрети. Для офшорной разработки и конвеера, это правда, для создания собственных высокотехнологичных продуктов продуктов — нет. Конкуренты (которые изобретают) сожрут. Я занимаюсь разработкой продуктов.

Здравствуйте, Alexey Chen, Вы писали:

AC>На тему не изобрети. Для офшорной разработки и конвеера, это правда, для создания собственных высокотехнологичных продуктов продуктов — нет. Конкуренты (которые изобретают) сожрут. Я занимаюсь разработкой продуктов.
Сильный аргумент. Опровергнуть не могу, т.к. продуктов не разрабатывал. Хотя нутром чую ( (С) В.Корнеев), что и там будет справедливо. Сведя изобретательство велосипедов к минимуму, ты высвободишь дорогостоящие изобретательские ресурсы на изобретение конкурентных преимуществ.

Здравствуйте, Sinclair, Вы писали:

AC>>На тему не изобрети. Для офшорной разработки и конвеера, это правда, для создания собственных высокотехнологичных продуктов продуктов — нет. Конкуренты (которые изобретают) сожрут. Я занимаюсь разработкой продуктов.
S>Сильный аргумент. Опровергнуть не могу, т.к. продуктов не разрабатывал. Хотя нутром чую ( (С) В.Корнеев), что и там будет справедливо. Сведя изобретательство велосипедов к минимуму, ты высвободишь дорогостоящие изобретательские ресурсы на изобретение конкурентных преимуществ.

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

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

Теперь о том, как это бывает в жизни. Продукт падает и в команию разработчика летит баг репорт с усеченным до разумного креш-дампом или просто стек трейсом и куском стека. Искал когда-нибудь багу в коде использующем буст, хотябы по полной корке? Занятие, я тебе скажу, не для слабонервных. Дык вот, с этим креш-дампом работать мне, и я не могу попросить повторить мне ситуацию подения раз так несколько в тепличных условиях. Тоесть я должен найти и исправить багу по той информации которую мне прислали. Это сильно меняет подход к разработке софта. Решения становятся максимально простыми и предельно прозрачнами. Изначально заточенными на последующий поиск ошибок при ограниченой информации.

Это то как работаю я. С другой стороны я наблюдаю картину, при которой любой велосипед считается априори убогим, причем без учета, что он кристально прозрачен и изначально заточен под задачу, не отягощен лишним мусором. Ведь этот велосипед не проистекает из истока истинного пути Modern С++ — STL и потомка его BOOST'а

Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, Курилка, Вы писали:

К>>Я не ослышался, или MFC нонче лучше STL считается? :shuffle:
AC>Я разве сказал лучше? :) Я привел вполне себе аргумент.

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

только это будет не С++-программер, а MFC-программер.
Потому что его нельзя будет использовать, например, в юниксовом проекте — там нету никакой MFC.

Это как раз напрямую касается вопроса о профпригодности.
Вот ты, насколько я понимаю, знаешь и понимаешь и STL, и boost, соответственно твоя ценность как программиста гораздо выше, чем ценность программиста, знающего только MFC, и уж подавно выше ценности программиста, знающего только свои велосипеды.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Alexey Chen, Вы писали:

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

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

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