Проф. пригодность, boost, Александреску и Ko - Священные войны

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

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

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

Все нижесказанное мое личное мнение:

Дело в том, что С++ был спроектирован очень давно. Со временем этот язык стал стандартом универсального языка программирования. Но потребности постоянно росли и на сегодня С++ не отвечает современным требованиям рынка. Однако в С++ было введено одно мощьнейшее средство — шаблоны. С их помощью оказалось возможно эмулировать недостающие вомзожности языки и даже отчасти переписывать язык. Именно это и просходит в бусти и на страницах книг Александреску. Я не раз говорил, что С++ нужно реформировать, и что метапрограммирование на шаблонах далеко от идеала. Но многие согласны мериться с сложность, неуклюжестью и т.п. ради общего комулитивного эффекта язка. Ну, что же... время все расставит на свои места. Шарп/дотнет и Ява уже отъели немалый кусок рынка у С++ и отъедание продолжается. Если С++ не будет развиваться дальше, то все Бусты и Алексондреску ему не помогут. Но пока они продливают жизнь этому заслуженному языку. Хорошо это или плохо вопрос сложный. С одной стороны С++ был бы значительно больше ограничен в средствах без них, но с другой именно эти фичи позволяют не развивать язык в нужных направлениях.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, Alexey Chen,

Послушай совет мудрых, Write in C а не на С++

Boost — непрозрачный и запутанный в первую очередь из-за того, что пытается поддержать максимум компиляторов, со всеми их ограничениями и ошибками.
Поэтому его и превозносят: во-первых, "всё украдено до нас", и не надо изобретать велосипед (если только компилятор может поддержать соответствующую фичу буста); во-вторых, более-менее единый подход, наследующий идеи STL.

Александреску — не только популяризатор.
Книга "Modern C++ Design" — это исследование того, как выстроить фреймворк в едином подходе. А результат этого исследования — библиотека Loki.

Про "конкретные и весьма не новые подходы" — огласите весь список пожалуйста.

).
Глядя на все эти конструкции голова идет кругом, это точно. А тольку от них мало... но зато, если разобрался, то писать приятно, причем чисто на индивидуальном уровне, т.е. "для себя" приятно, качество кода при этом скорее страдает. Страдает потому, что по опыту могу сказать, что 90%, а возможно и больше, программистов на С++ плохо разбираются в шаблонах и при виде нетривиальностей у них голова идет кругом.
Есть пара вещей, без которых трудно, но их немного. Например, ptr-ы, контейнеры и алгоритмы (кстати, их применение, почти всегда, тривиально, только если не встревают mem_func, бинды и т.д. Да и ну их в болото — без них проше!). Думаю, что этого вполне достаточно и остально скорее излишества, чем нечто приносяцее реальную пользу.
Я несколько лет писал на C++ и недавно перешел на java. Если честно, то доволен. Дискомфорта не испытываю. Зато теперь я забыл про язык и больше занят технологиями и бизнес-задачами. На мой взгляд, это большой плюс.

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

SK>Я несколько лет писал на C++ и недавно перешел на java. Если честно, то доволен. Дискомфорта не испытываю. Зато теперь я забыл про язык и больше занят технологиями и бизнес-задачами. На мой взгляд, это большой плюс.

У меня наоборот. После Шарпа припахали на небольшой проект на плюсах. Вою и лезу на стены!!! Хотя до этого тоже писал на ЦПП несколько лет.

... << RSDN@Home 1.1.4 beta 2 rev. 0>>

Про "решения в которых без бутылки водки не разберешся". Когда я в первый раз читал Александреску, меня прежде всего поразила способность человека взглянуть на задачу/проблему под несколько иным, нетрадиционным углом зрения. Водка здесь не при чем. Александреску так мыслит, и это его отличает от других авторов "про С++".

Про "светлое будущее всех C++ программеров". Часто ли глядя на С++ код других людей (саппорт, рефакторинг и т.п.) ты можешь сказать что это писал профессионал, понимающий язык и его возможности? Я — не часто. БУСТ — пример того, как в трех строчках кода записать свою мысль наиболее выразительно, используя всю мощь языка. Не в "стиле С", как тебе уже отвечали, а "в стиле С++".
То же самое про символы веры и правильный код. Точно, Александреску, Мейерс, Саттер, Ву, Липпман и др. — популяризаторы. Ну так и хорошо! Я — за то чтобы грамотность программиста С++ повышалась, а не падала. Эти ребята — противовес книжным полкам "learn C++ power in 21 days". Мне нравится их подход к языку и возникающим задачам программирования (и проектирование тоже). Предлагаются красивые, продуманные и безопасные решения типовых задач, вот и все.
Не знаю как кому, но мне не нужны книги по С++, в которых на 200 страницах будут расписывать как работает виртуальная функция. Есть спрос — есть и предложение. Саттер собрал в книги многолетний опыт решения проблем на С++, используя FAQ и Guru of the Week. Александреску предложил весьма интересные идеи метапрограммирования с использованием шаблонов. Не нужно относиться к этому как "для просвещенных", "понты", "супер-пупер-вы#%@ны".

Наконец, про "как связаны вещи перечисленные в сабже". В принципе то о чем говорят перечисленные товарищи, ничего сверхсложного не несет. Но с другой стороны, определенный уровень понимания проблемы должен наличествовать. Если ты можешь понять списки типов, генератор распределенных иерархий, смарт-поинтеры на основе стратегий, классы характеристик, обобщенные функторы, то с достаточной уверенностью можно сказать что С++ тебе совсем не чужд, и твои познания в области его применения не ограничиваются написанием "hello world".

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

M>Про "светлое будущее всех C++ программеров". Часто ли глядя на С++ код других людей (саппорт, рефакторинг и т.п.) ты можешь сказать что это писал профессионал, понимающий язык и его возможности? Я — не часто. БУСТ — пример того, как в трех строчках кода записать свою мысль наиболее выразительно, используя всю мощь языка. Не в "стиле С", как тебе уже отвечали, а "в стиле С++".
Я сам С++ люблю именно за всякие фичи, которые открываешь. И так можно, и этак, и еще вот эдак, блин!!!!!
Но вспоминаю высказывние одного гуру про язык APL: программу из 4 строчек он рашифровывал около 4 часов. Скоро С++ станет в этом смысле похож на APL.

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

К>Здравствуйте, Alexey Chen,

К>Послушай совет мудрых, Write in C а не на С++

Шутку понял, смешно.
Писать на C... в этом есть свой кайф

, но это совсем другой язык.

К>Boost — непрозрачный и запутанный в первую очередь из-за того, что пытается поддержать максимум компиляторов, со всеми их ограничениями и ошибками.
К>Поэтому его и превозносят: во-первых, "всё украдено до нас", и не надо изобретать велосипед (если только компилятор может поддержать соответствующую фичу буста); во-вторых, более-менее единый подход, наследующий идеи STL.
Дык, а зачем пытаться обьять необьятное? Особенность же 'наследует идеи STL' трудно назавать плюсом. Это именно особенность.
Кстати, идеи STL местами тоже слишком универсальны... в результате чего, меня, например, иногда упрекают, что здесь вот, я типа не использовал STL, а писал свое. Как же так? А то, что свое везде работает одинаково и в конкретном случае проще — не аргумент, ведь это противоречит вере в непогрешимость правильного подхода — 'не изобрети свой велосипед'. Воспользуйся, блин, готовым трактором. А если мне нужен именно легкий самокат, зачем мне трактор? Проблема то в том, что многие спецы считают что буст — решит все ваши проблемы, а как почему и сколько это будет стоить знать не надо, об этом уже подумали умные дяди.

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

К>Александреску — не только популяризатор.
К>Книга "Modern C++ Design" — это исследование того, как выстроить фреймворк в едином подходе. А результат этого исследования — библиотека Loki.
Да, согласен. Но данный труд написан, скорее как рекомендация к действию без упоменяния о пост-эффектах. Класическая схема ООП не так уж и плоха, только начитавшись данного исследования, об этом часто забывают. Я сам не могу себе представить программирование на C++ без шаблонов (могу конечно но очень не хочется), но всему есть свое место и время. На этом форуме, например, присутствует стремление все засунуть в такую гору шаблонов и макросов, что преимущества перед простой обьектной моделью, для меня, уже просто ускользают.

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

.... забыв при этом внмательно посмотреть, что я написал. Способ не новый, просто я не стал все это засовывать в гору макросов. Я не спорю что Александреску крут по поводу автогенерации кода по списку параметров, не уверен, что он сам это придумал, но идею он развил качественно. Хотя, имхо, этот раздел его исследования на практике бесполезен. Основное же, на что он напирает — параметризация стратегиями, далеко не новая идея, и вроде как, появилясь не в C++. В этом плане он выступает скорее как популизатор. И не всегда то, что он пишет хорошо подходит под задачи, о чем я кстати в его книге не видел ни слова. Но на своей практике я уже не раз видел тупой копипаст с примеров из замечательной (без кавычек) книги, без понимания почему и для чего. Святая вера, блин. Имхо, это плохо.

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

Если человек не спользует shared_ptr, а пишет свой класс в несколько строк, и не тянет за собой дцать метров сырков он ламер

Если он не использует мега-bind и function, а стыдно сказать, пишет свой кусочек кода в несколько строк он недостоен быть C++ программером

Да, мода рулит! Собственно, об этом я говорил, а не о том что в C++ не нужны шаблоны.

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

Это старая проблема — "дали мартышке пулемёт".
В общем, когда мартышка-программист, это не так страшно, по сравниению с мартышкой-менеджером

Так что можно не обращать внимание.

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

M>Про "решения в которых без бутылки водки не разберешся". Когда я в первый раз читал Александреску, меня прежде всего поразила способность человека взглянуть на задачу/проблему под несколько иным, нетрадиционным углом зрения. Водка здесь не при чем. Александреску так мыслит, и это его отличает от других авторов "про С++".
Дык, кто же спорит. Только приподносит он это как единственно верное решение. Мне например очень не понравилось, как он опустил компонентную архитектуру перед тем как начал задвигать про шаблоны. Зачем это надо было делать?

M>Про "светлое будущее всех C++ программеров". Часто ли глядя на С++ код других людей (саппорт, рефакторинг и т.п.) ты можешь сказать что это писал профессионал, понимающий язык и его возможности?
Я не смотрю кто его писал, я смотрю понятно ли он его писал. Понятно — это когда для того чтобы понять что написано, не надо долго морщить лоб и представлять во что развернется эта строчка, или при возникновении баги перелопачивать груду сырков. Понятный код, обычно локален.

M>То же самое про символы веры и правильный код. Точно, Александреску, Мейерс, Саттер, Ву, Липпман и др. — популяризаторы. Ну так и хорошо! Я — за то чтобы грамотность программиста С++ повышалась, а не падала.
Знаешь, мне почему-то казалось, что грамотность программиста — это умение писать алгоритмы и дизайнить архитектуру программы, а не умение свести в одной строчке кода дцать сущностей...

M>Не знаю как кому, но мне не нужны книги по С++, в которых на 200 страницах будут расписывать как работает виртуальная функция. Есть спрос — есть и предложение. Саттер собрал в книги многолетний опыт решения проблем на С++, используя FAQ и Guru of the Week. Александреску предложил весьма интересные идеи метапрограммирования с использованием шаблонов. Не нужно относиться к этому как "для просвещенных", "понты", "супер-пупер-вы#%@ны".
Вот и я о том же, но таки относятся, и чем дальше тем больше... Чем заковыристее bind, тем круче программер

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

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

LVV>Но вспоминаю высказывние одного гуру про язык APL: программу из 4 строчек он рашифровывал около 4 часов. Скоро С++ станет в этом смысле похож на APL.

Почему станет? Уже стал

Касательно APL.

На самом же деле, это простой язык матричных вычислений. Берём любую книгу по, скажем, матстатистике, цапаем оттуда какую-нибудь жирненькую формулу — как раз на 4 строчки, и долго-долго вчитываемся. Особенно, если пропустить 21 страницу комментариев.

Правда, у APL специфический синтаксис (все эти птички-кружочки) и порядок вычислений (слева направо без приоритетов, как у дешёвого калькулятора).
Дык берём matlab — там тоже всё с матрицами, но в ASCII. Кодируем упомянутую выше матстатистику, подсовываем студенту и злорадствуем.

Язык Lisp не от хорошей жизни расшифровывают как lots of idiotic stupid parentheses (тыщща идиотских скобок).
Он, конечно, помногословнее, чем APL — но тоже способен вогнать в транс.

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

К>

К>На самом же деле, это простой язык матричных вычислений. Берём любую книгу по, скажем, матстатистике, цапаем оттуда какую-нибудь жирненькую формулу — как раз на 4 строчки, и долго-долго вчитываемся. Особенно, если пропустить 21 страницу комментариев.
К>Правда, у APL специфический синтаксис (все эти птички-кружочки) и порядок вычислений (слева направо без приоритетов, как у дешёвого калькулятора).
Знаем-знаем! В студенчестве читал книгу про него на IBM.
К>Дык берём matlab — там тоже всё с матрицами, но в ASCII. Кодируем упомянутую выше матстатистику, подсовываем студенту и злорадствуем.

К>

К>Язык Lisp не от хорошей жизни расшифровывают как lots of idiotic stupid parentheses (тыщща идиотских скобок).
К>Он, конечно, помногословнее, чем APL — но тоже способен вогнать в транс/
Да, это точно!

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

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

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

AC>Кстати, идеи STL местами тоже слишком универсальны...
так и должно быть и в BOOST тоже самое, на то оно и обобщённое программирование.

AC>в результате чего, меня, например, иногда упрекают, что здесь вот, я типа не использовал STL, а писал свое.
А зачем писать своё если есть готовое проверенное решение

AC>А то, что свое везде работает одинаково
А STL и BOOST тоже везде работают одинаково

AC> и в конкретном случае проще
а расширяемость?

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

AC>Проблема то в том, что многие спецы считают что буст — решит все ваши проблемы,
не все, но многие может решить

AC>а как почему и сколько это будет стоить знать не надо
по хорошему конечно надо знать сколько будет стоить то или иное средство,

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

AC>Я сам не могу себе представить программирование на C++ без шаблонов (могу конечно но очень не хочется), но всему есть свое место и время.
золотые слова.

AC>Александреску крут
AC>Но на своей практике я уже не раз видел тупой копипаст с примеров из замечательной (без кавычек) книги, без понимания почему и для чего.
тупой копипаст — это плохо. Согласен

AC>Святая вера, блин. Имхо, это плохо.
Вы наверно имели ввиду слепая вера?
если да, то тоже согласен.
слепая вера — это плохо

AC>Если человек не спользует shared_ptr, а пишет свой класс в несколько строк
shared_ptr в несколько строк не напишешь, это очень мощная штука.

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

AC>Да, мода рулит! Собственно, об этом я говорил, а не о том что в C++ не нужны шаблоны.

Ну в общем я думаю в конце этой дискуссии мы прийдём к выводу что как всегда виновата прокладка между стулом и монитором

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

AC>Если человек не спользует shared_ptr, а пишет свой класс в несколько строк, и не тянет за собой дцать метров сырков он ламер

AC>Если он не использует мега-bind и function, а стыдно сказать, пишет свой кусочек кода в несколько строк он недостоен быть C++ программером

Да, мода рулит! Собственно, об этом я говорил, а не о том что в C++ не нужны шаблоны.

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

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

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

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

Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

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

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

M>>Про "светлое будущее всех C++ программеров". Часто ли глядя на С++ код других людей (саппорт, рефакторинг и т.п.) ты можешь сказать что это писал профессионал, понимающий язык и его возможности? Я — не часто. БУСТ — пример того, как в трех строчках кода записать свою мысль наиболее выразительно, используя всю мощь языка. Не в "стиле С", как тебе уже отвечали, а "в стиле С++".
LVV>Я сам С++ люблю именно за всякие фичи, которые открываешь. И так можно, и этак, и еще вот эдак, блин!!!!!
LVV>Но вспоминаю высказывние одного гуру про язык APL: программу из 4 строчек он рашифровывал около 4 часов. Скоро С++ станет в этом смысле похож на APL.

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

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

SK>Думаю, что никак. Людей, которые обожают C++ для всего (т.е. говорят, что это универсальный современный язык, а не низкоуровневое средство), на мой взгляд, можно вполне назвать синтаксическими онанистами (только не бейте

).

Ударим железным кулаком синтаксического онанизма по компонентной проституции!

... << RSDN@Home 1.1.3 stable >>

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

JJ>И все потому, что в той фирме как раз и сидят такие люди, которых жутко прет писать свои классы, а гемор, который потом придется разгребать пользователям их чудо-класса — это уже не их дело, даже наоборот — пока есть баги, нужна их поддержка, т.е. к ним приедет еще бабла, и т.д., и т.п.
Что-то мне подсказывает, что STL и BOOST там не помогут, хотя возможно я и ошибаюсь

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

Хм, STL... переезд с одной версии копилятора на другую, резкое падение производительности.... предолжения?
Основных причины было две, по другому реализованы алокаторы и list имел линейную сложность для size().
Про std::string на нескольких процессорах вспоминать будем?

J>Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

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

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

VD>Все нижесказанное мое личное мнение:
Use IMHO as default — on

VD>Дело в том, что С++ был спроектирован очень давно. Со временем этот язык стал стандартом универсального языка программирования. Но потребности постоянно росли и на сегодня С++ не отвечает современным требованиям рынка. Однако в С++ было введено одно мощьнейшее средство — шаблоны. С их помощью оказалось возможно эмулировать недостающие вомзожности языки и даже отчасти переписывать язык. Именно это и просходит в бусти и на страницах книг Александреску. Я не раз говорил, что С++ нужно реформировать, и что метапрограммирование на шаблонах далеко от идеала. Но многие согласны мериться с сложность, неуклюжестью и т.п. ради общего комулитивного эффекта язка.
Прости, а что ты называешь в данном случае "кумулятивным эффектом"?

VD>Ну, что же... время все расставит на свои места. Шарп/дотнет и Ява уже отъели немалый кусок рынка у С++ и отъедание продолжается. Если С++ не будет развиваться дальше, то все Бусты и Алексондреску ему не помогут. Но пока они продливают жизнь этому заслуженному языку.
Я скажу больше — VBA тоже имеет немалый кусок рынка. И что из того? C++ развивался совсем не имея в качестве цели монополизацию рынка. Так что, подобные аналогии здесь — "мимо кассы". Вопрос же не в массовости...

VD>Хорошо это или плохо вопрос сложный. С одной стороны С++ был бы значительно больше ограничен в средствах без них, но с другой именно эти фичи позволяют не развивать язык в нужных направлениях.
Правильно, потому что ответом на "новое направление" часто может быть только новая группа шаблонов. Чего шум-то поднимать?

... << RSDN@Home 1.1.3 stable >>

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

K>Здравствуйте, Alexey Chen, Вы писали:
AC>> и в конкретном случае проще
K>а расширяемость?
А вседа ли она нужна, и в каком виде? Расширять то можно тоже по разному.

AC>>в результате чего, меня, например, иногда упрекают, что здесь вот, я типа не использовал STL, а писал свое.
K>А зачем писать своё если есть готовое проверенное решение
Вспомним замечательный std::string, который фиг знает как работает, сколько памяти занимает, и в некоторых версиях компилиров не может содежать UNICODE и передаваться за пределы модуля (DLL)? У С++ очень странный стандарт.Это даже не стандарт, а рекомендации.
И полагать, что код сделаный из учета этих рекомендаций будет работать везде и всегда.... можно конечно, до первого столба.

AC>>Класическая схема ООП не так уж и плоха, только начитавшись данного исследования, об этом часто забывают.
K>А причём тут ООП и книга Александреску?
Он очень интересно относится к динамическим системам, ставя во главу угла статику. Причем очень жёстко очерчивая свою позицию.
Конкретно глава 1.2. Особенно мне понравилось про огромный размер и интеллектульные издержки... нет, это не про шаблоны.
Хм, размышления в этой главе относятся к очень узкому кругу задач и местами высосны из пальца. Но тем неменее, предодносятся как единственно верные. Java,C#,Eiffel и т.д. — 'очевидно, что идти этим путем не следует'. Вот именно за это я и не люблю популистов!

AC>>Если человек не спользует shared_ptr, а пишет свой класс в несколько строк
K>shared_ptr в несколько строк не напишешь, это очень мощная штука.
Хм, зависит от потребностей. Вам всегда были нужны все возможности? У меня есть проекты где достаточно класса в несколько строк кода. Но зато этот код локален, легко интегрируем и прозрачен.

C STL'ем все ясно и я от него не в восторге, излишеств в нем тоже хватает. Но мне действительно не понятно, зачем нужем такой монстр как BOOST, кроме как для академических целей. И зачем его тащить в стандарт? Это я к тому что последнее время часто слышу фразу типа — 'как? вы не используете boost — это же следующий стандарт!'.

JJ>>И все потому, что в той фирме как раз и сидят такие люди, которых жутко прет писать свои классы, а гемор, который потом придется разгребать
пользователям их чудо-класса — это уже не их дело, даже наоборот — пока есть баги, нужна их поддержка, т.е. к ним приедет еще бабла, и т.д., и т.п.
AC>Что-то мне подсказывает, что STL и BOOST там не помогут, хотя возможно я и ошибаюсь

Помогут. Вы бы видели ЭТИ хэши. И ЭТИ списки.

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

ГВ>Прости, а что ты называешь в данном случае "кумулятивным эффектом"?

Моё имхо — кумулятивный эффект здесь — это
* количество уже написанного кода
* количество людей, знающих вот такой язык и умеющих на нём писать (причём не просто рожать wellformed код,
* количество компиляторов, наконец (с учётом сложности языка — это важный факт)

Благодаря этому вовсю живёт Fortran. Правда, F-90 уже больше напоминает VB6, но старообрядцы до сих пор могут насладиться его подмножеством (!) F-IV.

VD>>Хорошо это или плохо вопрос сложный. С одной стороны С++ был бы значительно больше ограничен в средствах без них, но с другой именно эти фичи позволяют не развивать язык в нужных направлениях.
ГВ>Правильно, потому что ответом на "новое направление" часто может быть только новая группа шаблонов. Чего шум-то поднимать?

Этак можно всё вообще свести к макросам. Например, базовые библиотеки TurboPascal 5.5 кто-нибудь видел? ООП на макроассемблере...

Есть же ряд вещей, которые удобнее, будучи свойствами языка, а не извращениями библиотек.
Примеры — лямбда-исчисление, развитое RTTI, мультиметоды несчастные...

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

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

K>>Здравствуйте, Alexey Chen, Вы писали:
AC>>> и в конкретном случае проще
K>>а расширяемость?
AC>А вседа ли она нужна, и в каком виде? Расширять то можно тоже по разному.
Программа, которая не меняется — никому не нужна. (c) что-то из законов Мерфи. Так что правильный ответ на твой вопрос — всегда или почти всегда.

AC>>>в результате чего, меня, например, иногда упрекают, что здесь вот, я типа не использовал STL, а писал свое.
K>>А зачем писать своё если есть готовое проверенное решение
AC>Вспомним замечательный std::string, который фиг знает как работает, сколько памяти занимает, и в некоторых версиях компилиров не может содежать UNICODE и передаваться за пределы модуля (DLL)? У С++ очень странный стандарт.Это даже не стандарт, а рекомендации.
Вообще-то, сие от менеджера памяти зависит, а не от компилятора. И ещё — от конфигурации runtime libraries.

AC>И полагать, что код сделаный из учета этих рекомендаций будет работать везде и всегда.... можно конечно, до первого столба.
Угу. Был такой. Говорят, он быстроходен, даже неуловим. MSVC6 назывался. Всем столбам забор. До сих пор отмахаться от его буйного наследия не можем.

AC>>>Класическая схема ООП не так уж и плоха, только начитавшись данного исследования, об этом часто забывают.
K>>А причём тут ООП и книга Александреску?
AC>Он очень интересно относится к динамическим системам, ставя во главу угла статику.
Он ставит во главу угла перенос контроля цельности кода на компилятор. И настройку реализует о тем же принципам. И что тут плохого? ИМХО, более чем правильно поступает.

AC>Причем очень жёстко очерчивая свою позицию.
А как её надо очерчивать в своей книге? Сказать: "Извините, я, конечно, балбес, но не будуте ли вы столь любезны..."? Самому-то не смешно? Книга — это просто книга. Не нравится — не читай.

AC>Конкретно глава 1.2. Особенно мне понравилось про огромный размер и интеллектульные издержки... нет, это не про шаблоны.
AC>Хм, размышления в этой главе относятся к очень узкому кругу задач и местами высосны из пальца. Но тем неменее, предодносятся как единственно верные. Java,C#,Eiffel и т.д. — 'очевидно, что идти этим путем не следует'. Вот именно за это я и не люблю популистов!
А точнее можно? Ты всех полпулистов не любишь или только С++-ных?

AC>>>Если человек не спользует shared_ptr, а пишет свой класс в несколько строк
K>>shared_ptr в несколько строк не напишешь, это очень мощная штука.
AC>Хм, зависит от потребностей. Вам всегда были нужны все возможности? У меня есть проекты где достаточно класса в несколько строк кода. Но зато этот код локален, легко интегрируем и прозрачен.
Возможно, что для твоей задачи это и адекватно. Но именно с "локальным" кодом и многократным изобретением велосипедов в рамках одного проекта может быть такое количество проблем!!! Надеюсь, не мне тебе рассказывать.

AC>C STL'ем все ясно и я от него не в восторге, излишеств в нем тоже хватает. Но мне действительно не понятно, зачем нужем такой монстр как BOOST, кроме как для академических целей. И зачем его тащить в стандарт? Это я к тому что последнее время часто слышу фразу типа — 'как? вы не используете boost — это же следующий стандарт!'.
А я вот нечасто использую. Но дискомфорта от вероятного введения его в стандарт не испытываю. Равно как и от воплей. Пусть шумят те, кому нравится.

... << RSDN@Home 1.1.3 stable >>

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

J>Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

Не судьба мне у тебя работать.

... << RSDN@Home 1.1.0 stable >>

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

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

K>ну во-первых спасибо за поднятие интересной темы, хотя она рискует перерасти в нехилый флейм, ну да ладно...

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

AC>>Кстати, идеи STL местами тоже слишком универсальны...
K>так и должно быть и в BOOST тоже самое, на то оно и обобщённое программирование.

Это называется -- универсальное средство для решения всех задач, только вот для решения конкретных задач оно или не подходит вообще, или обходиться чудовищно дорого.
Да вот, недавний пример махрового STиLизма http://www.rsdn.ru/forum/Message.aspx?mid=835728&only=1.
В программировании слишком сильный уровень абстракций -- вреден. Почитай Джоела про "Закон дырявых абстракций".

AC>>в результате чего, меня, например, иногда упрекают, что здесь вот, я типа не использовал STL, а писал свое.
K>А зачем писать своё если есть готовое проверенное решение

НЕТ решения, в этом всё и дело.

AC>>А то, что свое везде работает одинаково
K>А STL и BOOST тоже везде работают одинаково

Это неправда.

AC>> и в конкретном случае проще
K>а расширяемость?

AC>>Воспользуйся, блин, готовым трактором. А если мне нужен именно легкий самокат, зачем мне трактор?
K>а вот это уже аргумент.
K>мне вот недавно нужен был простейший токенайзер, взял бустовский, посмотрел, повертел и не стал его использовать
K>потому что действительно для моей задачи это был скорее не велосипед, а трактор.
K>Написал свой токенайзер, который работает в несколько раз быстрее бустовского.

Ну вот видишь.

AC>>Проблема то в том, что многие спецы считают что буст — решит все ваши проблемы,
K>не все, но многие может решить

Большинство проблем, которые решает boost -- надуманные.

AC>>Если человек не спользует shared_ptr, а пишет свой класс в несколько строк
K>shared_ptr в несколько строк не напишешь, это очень мощная штука.

Это очень злементарная штука.

AC>>Александреску и Маерс это плохие специалисты, я про то, что их книги это популизация методик
K>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг.
K>А вот Саттера и Мейерса очень рекомендую.
K>Именно как популизацию грамотного стиля и методик программирования на C++.

Все трое -- ламеры.

... << RSDN@Home 1.1.0 stable >>

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

К>Благодаря этому вовсю живёт Fortran. Правда, F-90 уже больше напоминает VB6, но старообрядцы до сих пор могут насладиться его подмножеством (!) F-IV.

Ясно.

VD>>>Хорошо это или плохо вопрос сложный. С одной стороны С++ был бы значительно больше ограничен в средствах без них, но с другой именно эти фичи позволяют не развивать язык в нужных направлениях.
ГВ>>Правильно, потому что ответом на "новое направление" часто может быть только новая группа шаблонов. Чего шум-то поднимать?

К>Этак можно всё вообще свести к макросам. Например, базовые библиотеки TurboPascal 5.5 кто-нибудь видел? ООП на макроассемблере...
Э, не путай калий с кальцием. Шаблоны и макросы — не одно и то же. Хм. Кодт, это я тебе рассказываю или у тебя дубль появился?

К>Есть же ряд вещей, которые удобнее, будучи свойствами языка, а не извращениями библиотек.
К>Примеры — лямбда-исчисление, развитое RTTI, мультиметоды несчастные...
Ну не всё же это должно быть в рамках одного языка.

Да и совмещать одно с другим совсем не очень удобно. Историю PL/1 все помнят, надеюсь? Хотя от мультиметодов я бы не отказался.

К>Это же не просто частные случаи, мол, захотелось мне башню построить, чтоб Парыж было видно. Ради одной башни и одного Парыжу, ладно уж, озадачу крепостных, они мне без единого гвоздя что-нибудь изгвоздают. Это фундамент. А если сотни, нет, тысячи бояр по всей земле-матушке хотят Парыж увидать, и тыщщи, нет мильёны крепостных ради этого корячатся каждый на свой лад. Революцiонная ситуация налицо.
А к чему пассаж? C++ — это, грубо говоря, те самые гвозди и металлические заводы в одном лице. Эдак мы до чего угодно договориться можем. Ну, хотят бояре на Парыж поглядеть — так хто ж им помешаить? Берём сертифицированого строителя Парыжей...

... << RSDN@Home 1.1.3 stable >>

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

AC>Хм, задача, нужно переключать контексты при нотификации кондишина, не как получится, а по порядку. Решение?
AC>Не забываем что хип в многопоточноп коде — просад производительноси в 5-10 раз.

Не всегда, не везде и зависит от. Ну как тут не вспомнить одиозное высказывание: "Почитайте Элджера/Александреску"!?

... << RSDN@Home 1.1.3 stable >>

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

ГВ>Не всегда, не везде и зависит от. Ну как тут не вспомнить одиозное высказывание: "Почитайте Элджера/Александреску"!?
Это, в некотром смысле, короткий анекдот

А про 'зависит от', я просто привел пример кторый НИ КАК НЕ ВПИСЫВАЕТСЯ в концепцию STL'я, хотя, через задний проход все можно сделать.

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

AC>Но мне действительно не понятно, зачем нужем такой монстр как BOOST, кроме как для академических целей.
Ну там тоже есть приятные библиотеки. Например boost/preprocessor иногда очень полезна и ее использование вобщем ни чего не стоит.
AC>И зачем его тащить в стандарт?
Дело в том что скажем биндеры в STL сделаны мягко говоря криво. boost::bind на порядок удобней.
Хотя по мне так нужны анонимные методы на уровнь языка вынести. Тогда все эти биндеры вымрут сами собой за ненадобностью.

... << RSDN@Home 1.1.4 rev. 185 >>

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

AC>>А вседа ли она нужна, и в каком виде? Расширять то можно тоже по разному.
ГВ>Программа, которая не меняется — никому не нужна. (c) что-то из законов Мерфи. Так что правильный ответ на твой вопрос — всегда или почти всегда.
Не надо смешивать расширяемость программы и расширяемость класса/компоненты. Есть очень стабильные интерфейсы/классы которые НЕ МЕНЯЮТСЯ.

AC>>Вспомним замечательный std::string, который фиг знает как работает, сколько памяти занимает, и в некоторых версиях компилиров не может содежать UNICODE и передаваться за пределы модуля (DLL)? У С++ очень странный стандарт.Это даже не стандарт, а рекомендации.
ГВ>Вообще-то, сие от менеджера памяти зависит, а не от компилятора. И ещё — от конфигурации runtime libraries.
В результате от компилятора.
AC>>И полагать, что код сделаный из учета этих рекомендаций будет работать везде и всегда.... можно конечно, до первого столба.
ГВ>Угу. Был такой. Говорят, он быстроходен, даже неуловим. MSVC6 назывался. Всем столбам забор. До сих пор отмахаться от его буйного наследия не можем.
Хм, пробывал отрезать менеджер памяти от Solaris/GCC или весь STL? А от Sun C++ у которого два STL'я и работают по разному? Там вообще все в шаред-либах, шаг в лево-вправо и unresolved symbol. А ведь есть еще CodeWarrior? А уж STL для EVC вообще песня

. Работа у меня такая, что Vc7 это не самый главный компилер, а так для быстрого тестирования.

K>>>А причём тут ООП и книга Александреску?
AC>>Он очень интересно относится к динамическим системам, ставя во главу угла статику.
ГВ>Он ставит во главу угла перенос контроля цельности кода на компилятор. И настройку реализует о тем же принципам. И что тут плохого? ИМХО, более чем правильно поступает.
Угу, компонентная архитектура маст дай? Что, обычный полиморфизм скончался от старости и теперь в ходу только статический, а прогу мы перекомпиливаем каждый раз полностью и по новой? Таки Альксандреску вбивает читателям именно эту идею. Не надо забывать, что шаблоны (статическая параметризация) это ОДИН из МНОЖЕСТВА вариантов решения задачи, не единственный и не всегда самый лучший.

AC>>Причем очень жёстко очерчивая свою позицию.
ГВ>А как её надо очерчивать в своей книге? Сказать: "Извините, я, конечно, балбес, но не будуте ли вы столь любезны..."? Самому-то не смешно? Книга — это просто книга. Не нравится — не читай.
Нет не смешно, мне грустно, поскольку эту книгу превозносят как символ кул-программинга. О чем собственно и топик.

ГВ>А точнее можно? Ты всех полпулистов не любишь или только С++-ных?
Ну еще проповедников не люблю, эффект очень похожий.

ГВ>Возможно, что для твоей задачи это и адекватно. Но именно с "локальным" кодом и многократным изобретением велосипедов в рамках одного проекта может быть такое количество проблем!!! Надеюсь, не мне тебе рассказывать.
А рамках разных или в рамках команды? Я понимаю что многие верят, что использовать тяжёлый трактор в котором без механика не разберешся, когда нужен именно велосипед, это круто! Только не понимаю почему.

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

AC>>И зачем его тащить в стандарт?
WH>Дело в том что скажем биндеры в STL сделаны мягко говоря криво. boost::bind на порядок удобней.
Я ими и не пользуюсь. Уже года два, как пришёл к выводу, что лучше нормально код написать. Хотя раньше было дело, такое закручивал...
WH>Хотя по мне так нужны анонимные методы на уровнь языка вынести. Тогда все эти биндеры вымрут сами собой за ненадобностью.
Дык. Вот я тоже о том и думаю. Но сомниваюсь, что комитет пойдет на это, мелкомягки да, они возможно сделают, а комитет.... фиг их знает, они скорее весь буст в стандарт втянут.

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

K>>А зачем писать своё если есть готовое проверенное решение
Ш>НЕТ решения, в этом всё и дело.
ЕСТЬ
-------------------------------------------------------------------------

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

Ш>Ну вот видишь.

а я и не спорю
я не фанат BOOST'а, не сую 4-х этажные шаблоны где не попадя и тд.

я за умное, расчётливое, без фанатизма, использование готовых инструментов.
Если мне готовое не подходит я пишу своё.
-------------------------------------------------------------------------

Ш>Большинство проблем, которые решает boost -- надуманные.

ну вот что я использую из boost в текущем проекте:
1. boost::lexical_cast
использую, потому что lexical_cast удобно использовать в шаблонном коде
и он бросает исключение в случае неудачи. То есть это то что мне нужно.
Там примерно такой код

template<typename T>
void parser::parse_value(T& value)
{
  if (m_tok.next())
  {
    tokenizer::token tk = m_tok.current_token();

    value = boost::lexical_cast<T>(std::string(tk.ptr, tk.len));
  }
}

2. boost::numeric_cast
сейчас я работаю со старым проектом.
там много вычислений, а так же много преобразований из целых в вещественные и обратно.
старый код менять не стал, потому что работает и слава богу
в местах числовых преобразований вставил numeric_cast,
чтоб потом не мучиться и не искать ошибку из-за обрезания числа.

3. boost::shared_ptr
4. boost::scoped_ptr
5. stl::auto_ptr
не хочу думать об освобождении памяти, ну и в случае исключения всё почистится

6. boost::bind
удобно
-------------------------------------------------------------------------

K>>shared_ptr в несколько строк не напишешь, это очень мощная штука.
Ш>Это очень злементарная штука.
а элементарная штука не может быть мощной?
-------------------------------------------------------------------------

K>>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг.
K>>А вот Саттера и Мейерса очень рекомендую.

Ш>Все трое -- ламеры.
ну вы хоть согласны, что среди ламеров они всё таки не самые ламеристые?

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

К>Это же не просто частные случаи, мол, захотелось мне башню построить, чтоб Парыж было видно. Ради одной башни и одного Парыжу, ладно уж, озадачу крепостных, они мне без единого гвоздя что-нибудь изгвоздают. Это фундамент.
К>А если сотни, нет, тысячи бояр по всей земле-матушке хотят Парыж увидать, и тыщщи, нет мильёны крепостных ради этого корячатся каждый на свой лад. Революцiонная ситуация налицо.

Красиво сказал

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

ГВ>Прости, а что ты называешь в данном случае "кумулятивным эффектом"?

КУМУЛЯЦИЯ — Концентрация взрывной энергии в снаряде, гранате, бомбе и т.п.

кумулятивным эффектом — соотвественно — эффект накопления заряда. В данном случае подразумевается суммирование различных факторов повышающих привлекательность использования С++.

VD>>Ну, что же... время все расставит на свои места. Шарп/дотнет и Ява уже отъели немалый кусок рынка у С++ и отъедание продолжается. Если С++ не будет развиваться дальше, то все Бусты и Алексондреску ему не помогут. Но пока они продливают жизнь этому заслуженному языку.
ГВ>Я скажу больше — VBA тоже имеет немалый кусок рынка. И что из того?

То что VBA никогда не пересекался с С++ на рынке. А Шарп и донет отедают у плюсов их исконные рыночные ниши. Уже даже игры начали писать на Шарпе. Что уж там говорить о области ИТ на который дотнет и был ориентирован изначально.

ГВ> C++ развивался совсем не имея в качестве цели монополизацию рынка. Так что, подобные аналогии здесь — "мимо кассы". Вопрос же не в массовости...

Я что-то вообщ не уловил смысла в высказываниях про кассы и монополизацию.

Ну, да думай как хочешь. Я высказал свое мнение.

VD>>Хорошо это или плохо вопрос сложный. С одной стороны С++ был бы значительно больше ограничен в средствах без них, но с другой именно эти фичи позволяют не развивать язык в нужных направлениях.
ГВ>Правильно, потому что ответом на "новое направление" часто может быть только новая группа шаблонов. Чего шум-то поднимать?

А шум в общем-то уже и не поднимается. Я свое мнеие уже высказал. Подобная консервативная позиция со временим выведет плюсы из болшинства хлебных ниш производства ПО. Ну, а кто прав покажет время.

Не согласен? Ну, и бог с тобой.

... << RSDN@Home 1.1.4 beta 2 >>

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

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

SK>>Я несколько лет писал на C++ и недавно перешел на java. Если честно, то доволен. Дискомфорта не испытываю. Зато теперь я забыл про язык и больше занят технологиями и бизнес-задачами. На мой взгляд, это большой плюс.

С>У меня наоборот. После Шарпа припахали на небольшой проект на плюсах. Вою и лезу на стены!!! Хотя до этого тоже писал на ЦПП несколько лет.

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

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

... << RSDN@Home 1.1.4 beta 2 >>

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

M>БУСТ — пример того, как в трех строчках кода записать свою мысль наиболее выразительно, используя всю мощь языка. Не в "стиле С", как тебе уже отвечали, а "в стиле С++".

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

... << RSDN@Home 1.1.4 beta 2 >>

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

К>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Прости, а что ты называешь в данном случае "кумулятивным эффектом"?

К>Моё имхо — кумулятивный эффект здесь — это
К>* количество уже написанного кода
К>* количество людей, знающих вот такой язык и умеющих на нём писать (причём не просто рожать wellformed код,
К>* количество компиляторов, наконец (с учётом сложности языка — это важный факт)

К>Благодаря этому вовсю живёт Fortran. Правда, F-90 уже больше напоминает VB6, но старообрядцы до сих пор могут насладиться его подмножеством (!) F-IV.

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

[]

К>Этак можно всё вообще свести к макросам. Например, базовые библиотеки TurboPascal 5.5 кто-нибудь видел?

Угу. Видал. Как принято здесь говорить — "не стоит путать тёплое с мягким". BTW, не вижу противоречия — любой ООП (каким бы ОО он ни был) втыкается в конце концов в средства ОС. Поговорим об ОО в ДОСе

Nothing personal, please

К>Есть же ряд вещей, которые удобнее, будучи свойствами языка, а не извращениями библиотек.
К>Примеры — лямбда-исчисление, развитое RTTI

У. Я понимаю, полемика. Но низзя же так.......

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

Сорри. Помедитировал. И въехал — тут таки имелась в виду "перечисление", а не "обобщение". Уж очень удивило лямбда и RTTI рядом

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

ГВ>>Прости, а что ты называешь в данном случае "кумулятивным эффектом"?
VD>

КУМУЛЯЦИЯ — Концентрация взрывной энергии в снаряде, гранате, бомбе и т.п.

VD>кумулятивным эффектом — соотвественно — эффект накопления заряда. В данном случае подразумевается суммирование различных факторов повышающих привлекательность использования С++.

Тут на самом деле не в C++ всё упирается, а в фон-неймановскую модель компьютера. Хорошо бы от неё свалить, но — увы, увы. Пока что.

VD>>>Ну, что же... время все расставит на свои места. Шарп/дотнет и Ява уже отъели немалый кусок рынка у С++ и отъедание продолжается. Если С++ не будет развиваться дальше, то все Бусты и Алексондреску ему не помогут. Но пока они продливают жизнь этому заслуженному языку.
ГВ>>Я скажу больше — VBA тоже имеет немалый кусок рынка. И что из того?
VD>То что VBA никогда не пересекался с С++ на рынке. А Шарп и донет отедают у плюсов их исконные рыночные ниши. Уже даже игры начали писать на Шарпе. Что уж там говорить о области ИТ на который дотнет и был ориентирован изначально.

Ну, я так думаю, что это будет способствовать развитию языка. Почему? Потому что меньше бестолкового шума будет подниматься. И потому, что останутся те, кто не думает расставаться с подобной культурой программирования. Хотя может быть, что C++ в конечном итоге вообще исчезнет с программистского горизонта. Значит — появится что-то, что намного лучше. Ну и фиг тогда с ним будет. Проблема не в этом. Проблема в том, что C++ на сегодня чуть ли не единственный, кто позволяет оптимизировать программу вплоть до уровня, сопоставмимого с ассемблером. При этом — оставаясь яыком высокого уровня, от культуры и основных принципов которого ни Java ни C# на сегодня очень недалеко ушли. А если называть вещи своими именами — то ещё и не догнали. Вот когда я смогу гладко вписать в C# (а равно и в Java) регистровую модель процессора — вот там и поговорим.

ГВ>> C++ развивался совсем не имея в качестве цели монополизацию рынка. Так что, подобные аналогии здесь — "мимо кассы". Вопрос же не в массовости...
VD>Я что-то вообщ не уловил смысла в высказываниях про кассы и монополизацию.

VD>Ну, да думай как хочешь. Я высказал свое мнение.

Я понял, что ты хотел сказать. Теперь.

VD>>>Хорошо это или плохо вопрос сложный. С одной стороны С++ был бы значительно больше ограничен в средствах без них, но с другой именно эти фичи позволяют не развивать язык в нужных направлениях.
ГВ>>Правильно, потому что ответом на "новое направление" часто может быть только новая группа шаблонов. Чего шум-то поднимать?
VD>А шум в общем-то уже и не поднимается. Я свое мнеие уже высказал. Подобная консервативная позиция со временим выведет плюсы из болшинства хлебных ниш производства ПО. Ну, а кто прав покажет время.

Меня забавляет другое. Естественно, "кто прав, кто не прав" — это не тема для обсуждения. Со временем сами разберёмся. Мы здесь просто диспутируем (это не опечатка).

Я расскажу одну историю. Мне недавно подсунули "для рассмотрения" логгер для C++ — log4cpp, который есть переделанный log4j. Мне ни тот ни другой по функциональным возможностям не нравятся, но это не суть. Вобщем, стал я мерять таки их быстродействие (критично было). Значит, цифры по внутренним издержкам были такие, в микросекундах, для простейшей конфигурации, под Windows 2K, усреднённые:

log4j — 50 (Sun JDK 1.4.что-то)
log4cpp — 25 (VC6, кажется)

Сразу признаюсь — не помню на чём именно такие цифры получены — не то на PIV-3,2, не то на Celeron 366. Суть в том, что соотношение — 1:2.

Ну я, разумеется, бардак почуял, ковырять пальцем в носе не стал, да и накатал свой. Так... по-быстрому. С внутренними издержками ~3 микросекунды (опять-таки, важно соотношение — ~1:6 по отношению к log4cpp). Функциональность — та же. Т.е. — конфигурирование и т.п. На C++, разумеется. Само собой — свои схемы управления памятью и параметризацией логгирования. Кстати — и то и то с привлечением темплейтов и у-у-ужасного пугала — множественного наследования. Ну ещё немного здоровой програмистской наглости и игнорирования авторитетов ОО (впрочем, это у меня уже давно "на автомате"). Потратил я на это, чтобы тебе не соврать, примерно 2 дня, работая "с пятого на десятое", т.е., не особо вдаваясь в детали оптимизации и высокого штиля софтостроения. Но не скажу, что решено всё было тривиально — уж извините, мы не из этой группы детского сада.

Выводы, как грится, делайте сами. Для ленивых выскажу кое-какие из своих.

1. Java — неплохое средство (не скрою — во многом она мне нравится своей стройностью), но увы. С управлением памятью всё пока ещё не слишком гладко. Возможно — дизайн кривой, хотя я не могу сказать, что что-то резануло мне глаз в log4j. Я как забросил идею общего корня со времён TP 5.5/6.0, так и не думаю к ней пока возвращаться.
2. Тупой перенос ОО-идиотизма Java на C++ ведёт к тяжёлому и медленному коду. А log4cpp — именно что тупо перенесённый log4j на C++. Там даже JVM-RTTI эмулирован. Цирк — да и только.

3. Тесты на шустрость отдельных конструкций языка — фигня полнейшая. Так, полоскалово мозгов для менеджеров. Да, где-то Java всего лишь на 30% отстаёт от C++. А по скорости виртуальных вызовов — почти догоняет. Но сумма. Увы. "Стройное дерево наследования" с одним общим корнем делает своё грязное дело. Строки, которыми на самом деле невозможно управлять — тоже. Так что, коллеги — дизайн и ещё раз дизайн. Как следствие того, что имеются:
а) небесконеченость конкретного компьютера;
б) модель уважаемого Фон-Нефймана, которая, к сожалению — рулит;
в) необходимость культуры програмирования компьютеров на том же C++. А не вой относительно "ОО — рулез форева" или "темплейты — рулез там же".

А потом уже — тесты на шустрость. И вот тут поглядим: кто — кого, откуда, куда, почему и откуда издержки.

VD>Не согласен? Ну, и бог с тобой.

Ну что ж!? Хорошее продолжение хорошей беседы!

Буду в ваших краях — заскочу всенепременно.

... << RSDN@Home 1.1.3 stable >>

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

AC>Не надо смешивать расширяемость программы и расширяемость класса/компоненты. Есть очень стабильные интерфейсы/классы которые НЕ МЕНЯЮТСЯ.
Ну хорошо. Уговорил, чёрт языкатый. Действительно — есть стабильные интерфейсы. Сам даже делаю такие.

AC>>>Вспомним замечательный std::string, который фиг знает как работает, сколько памяти занимает, и в некоторых версиях компилиров не может содежать UNICODE и передаваться за пределы модуля (DLL)? У С++ очень странный стандарт.Это даже не стандарт, а рекомендации.
ГВ>>Вообще-то, сие от менеджера памяти зависит, а не от компилятора. И ещё — от конфигурации runtime libraries.
AC>В результате от компилятора.

AC>Хм, пробывал отрезать менеджер памяти от Solaris/GCC или весь STL? А от Sun C++ у которого два STL'я и работают по разному? Там вообще все в шаред-либах, шаг в лево-вправо и unresolved symbol. А ведь есть еще CodeWarrior? А уж STL для EVC вообще песня

. Работа у меня такая, что Vc7 это не самый главный компилер, а так для быстрого тестирования.
Хммм... так. Сейчас как раз этим примерно и занимаюсь. Возможно, что я и ошибаюсь. Во всяком случае — кое что для солярки по части манагёра памятей я уже делал. Ты, кстати, какую версию Solaris имеешь ввиду? И какой компилятор? GCC или Forte? И кстати — что-то я не помню проблем при передаче std::string из одного .so в другой...

K>>>>А причём тут ООП и книга Александреску?
AC>>>Он очень интересно относится к динамическим системам, ставя во главу угла статику.
ГВ>>Он ставит во главу угла перенос контроля цельности кода на компилятор. И настройку реализует о тем же принципам. И что тут плохого? ИМХО, более чем правильно поступает.
AC>Угу, компонентная архитектура маст дай? Что, обычный полиморфизм скончался от старости и теперь в ходу только статический, а прогу мы перекомпиливаем каждый раз полностью и по новой?
По-новой, не по-новой, а деплоймент всё чаще состоит из инсталляционного CD... 640M бинарников на "просто компонеты" — не хрен собачий, согласись. Да и пользователи как-то привыкли: вот версия "10.39.41.150", а вот — "10.39.42.730". А то и ещё проще — "это мы получили две недели назад, а это — прямо сегодня".

AC>Таки Альксандреску вбивает читателям именно эту идею. Не надо забывать, что шаблоны (статическая параметризация) это ОДИН из МНОЖЕСТВА вариантов решения задачи, не единственный и не всегда самый лучший.
ИМХО, он вбивает чертовски правильную идею: "Товарищи! Переносите контроль на компилятор, а не на тестеров!" И только-то... Что громогласно повторяет та же MS. И правильно делает. Что через год-полтора "отлетает от зубов" у хороших C++-ников. И это тем более правильно. Никто не виноват в том, что от силы 10% програмистов становятся хорошими C++-никами. Возможно, что эти 10% как раз и составляли абсолютное большинство программистов в середине-конце 80-х. Блаженные времена...

AC>>>Причем очень жёстко очерчивая свою позицию.
ГВ>>А как её надо очерчивать в своей книге? Сказать: "Извините, я, конечно, балбес, но не будуте ли вы столь любезны..."? Самому-то не смешно? Книга — это просто книга. Не нравится — не читай.
AC>Нет не смешно, мне грустно, поскольку эту книгу превозносят как символ кул-программинга. О чем собственно и топик.
Ну, знаешь! Неокрепшие умы склонны создавать себе идолов в виде чего угодно. И что с того? Жалеешь, что не можешь к ним присоединиться?

Этой проблеме лет больше чем нам с тобой вместе взятым возведённым в степень количества RSDN-еров в top-5.

Не парься. Да, кстати, а Алексндреску-то тут при чём?

ГВ>>А точнее можно? Ты всех полпулистов не любишь или только С++-ных?
AC>Ну еще проповедников не люблю, эффект очень похожий.
Ну и кончай грузиться чепухой. Проповедникам — проповедниково. У проповедников свой хлеб, у нас — свой.

ГВ>>Возможно, что для твоей задачи это и адекватно. Но именно с "локальным" кодом и многократным изобретением велосипедов в рамках одного проекта может быть такое количество проблем!!! Надеюсь, не мне тебе рассказывать.
AC>А рамках разных или в рамках команды? Я понимаю что многие верят, что использовать тяжёлый трактор в котором без механика не разберешся, когда нужен именно велосипед, это круто! Только не понимаю почему.

Ну вот. Снова ошибка неправомерного агрегирования понятий. Обычно на месте трактора оказываются даже не гусеницы, а... воспоминания о тракторе, материализованные в виде велосипеда. С колёсами от F-1 и рулём от самолёта.

PS. Кстати, ты уж прости, но всё-таки — пробовал. Не сочти за наезд, но это тот случай, когда я готов получить свой законный moderatorial "+".

... << RSDN@Home 1.1.3 stable >>

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

ГВ>Тут на самом деле не в C++ всё упирается, а в фон-неймановскую модель компьютера. Хорошо бы от неё свалить, но — увы, увы. Пока что.

Да не причем тут абстрактные машины. Кто хотел свалил. Есть и дотнет, и ФЯ/ЛЯ и много чего еще.

ГВ>Ну, я так думаю, что это будет способствовать развитию языка. Почему? Потому что меньше бестолкового шума будет подниматься. И потому, что останутся те, кто не думает расставаться с подобной культурой программирования. Хотя может быть, что C++ в конечном итоге вообще исчезнет с программистского горизонта. Значит — появится что-то, что намного лучше. Ну и фиг тогда с ним будет.

Да они появляются причем некторые ооочень давно...

ГВ>Проблема не в этом. Проблема в том, что C++ на сегодня чуть ли не единственный, кто позволяет оптимизировать программу вплоть до уровня, сопоставмимого с ассемблером.

Да что-то я тут разницы с паскалем (дельфи) не замечаю. Да и до ассемблера С++-у далеко. А оптимизация она зависит не от языка, а от оптимизатора. А его можно почти для всего улучшать до предела. Достаточно сравнить оптимизаторы того же VC6 и VC8.

ГВ> При этом — оставаясь яыком высокого уровня, от культуры и основных принципов которого ни Java ни C# на сегодня очень недалеко ушли.

Да ушли, ушли. Их уже постоянно называют языками высокого уровеня в том, смысле что это уровень выше чем у С++.

ГВ> А если называть вещи своими именами — то ещё и не догнали.

Ну, это если совсем уж потерять связь с рельностью.

ГВ> Вот когда я смогу гладко вписать в C# (а равно и в Java) регистровую модель процессора — вот там и поговорим.

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

Миф о тормознутости дотета или явы устаривает с каждым годом. Они и сейчас не уступают многим компиляторам. А завтра вообще превзойдут всех их из-за возможности динамической оптимзации.

ГВ>...Выводы, как грится, делайте сами. Для ленивых выскажу кое-какие из своих.

Так и что твой рассказ то доказывает? Что медленную реализацию можно ускорить? Или ты считашь что доказал несостоятельность Явы таким макаром?

ГВ>1. Java — неплохое средство (не скрою — во многом она мне нравится своей стройностью), но увы. С управлением памятью всё пока ещё не слишком гладко.

Да все там ОК с памятью. Просто думать нужно как эффективнее алгоритмы делать. Единственное что в Яве с памятью не здорово, так это отсуствие структур. А так...

ГВ>2. Тупой перенос ОО-идиотизма Java на C++ ведёт к тяжёлому и медленному коду. А log4cpp — именно что тупо перенесённый log4j на C++. Там даже JVM-RTTI эмулирован. Цирк — да и только.

ГВ>3. Тесты на шустрость отдельных конструкций языка — фигня полнейшая. Так, полоскалово мозгов для менеджеров. Да, где-то Java всего лишь на 30% отстаёт от C++. А по скорости виртуальных вызовов — почти догоняет. Но сумма. Увы. "Стройное дерево наследования" с одним общим корнем делает своё грязное дело. Строки, которыми на самом деле невозможно управлять — тоже. Так что, коллеги — дизайн и ещё раз дизайн.

Сдается мне, что вера в скорость плюсов тебя подводит. Разбираться нужно или достконально, или вообще не разбираться. На уровен "вот одна реализация работает лучше другой на другом языке" можно наделать любых выводов. С Явой я особо не работаю. Знаю ее по тестам. Но скажу, что она медленнее дотнета всего чуть, чуть. А дотнет мало чем уступает тому же 6-ому VC. Так что если хочешь доказать обратно, то приводи конкретный код и тесты. Поглядим... сравним... поправим и перемерим.

ГВ> Как следствие того, что имеются:
ГВ>а) небесконеченость конкретного компьютера;

Серьезный аргумент. Я его даже не понял.

ГВ>б) модель уважаемого Фон-Нефймана, которая, к сожалению — рулит;

О! Еще белее серьезный аргумент. Жаль связь не просматривается.

ГВ>в) необходимость культуры програмирования компьютеров на том же C++. А не вой относительно "ОО — рулез форева" или "темплейты — рулез там же".

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

ГВ>А потом уже — тесты на шустрость. И вот тут поглядим: кто — кого, откуда, куда, почему и откуда издержки.

Да мы уже поглядели. Да не раз. И что-то никак не разглядим. А вот упрощение и ускорение разработки видно довольно четко.

... << RSDN@Home 1.1.4 beta 2 >>

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

ГВ>>Тут на самом деле не в C++ всё упирается, а в фон-неймановскую модель компьютера. Хорошо бы от неё свалить, но — увы, увы. Пока что.
VD>Да не причем тут абстрактные машины. Кто хотел свалил. Есть и дотнет, и ФЯ/ЛЯ и много чего еще.

От фон-неймановской модели — свалить?

ГВ>>Ну, я так думаю, что это будет способствовать развитию языка. Почему? Потому что меньше бестолкового шума будет подниматься. И потому, что останутся те, кто не думает расставаться с подобной культурой программирования. Хотя может быть, что C++ в конечном итоге вообще исчезнет с программистского горизонта. Значит — появится что-то, что намного лучше. Ну и фиг тогда с ним будет.
VD>Да они появляются причем некторые ооочень давно...

Угу, поверю на слово, ибо глазам своим уже давно не верю.

Вроде была разработка C++ с ограничениями — D, что ли...

ГВ>>Проблема не в этом. Проблема в том, что C++ на сегодня чуть ли не единственный, кто позволяет оптимизировать программу вплоть до уровня, сопоставмимого с ассемблером.
VD>Да что-то я тут разницы с паскалем (дельфи) не замечаю. Да и до ассемблера С++-у далеко. А оптимизация она зависит не от языка, а от оптимизатора. А его можно почти для всего улучшать до предела. Достаточно сравнить оптимизаторы того же VC6 и VC8.

Можно... Нельзя... Да, вообще-то можно почти всё. Но есть разница. В одном случае я могу всё сделать сам не дожидаясь реакции производителя, а вот в остальных... И почему-то совсем не каждый юзер желает немедленно обновлять парк техники по случаю выхода очередной версии Windows, .Net или JDK... Doom3 как-то лучше стимулирует.

ГВ>> При этом — оставаясь яыком высокого уровня, от культуры и основных принципов которого ни Java ни C# на сегодня очень недалеко ушли.
VD>Да ушли, ушли. Их уже постоянно называют языками высокого уровеня в том, смысле что это уровень выше чем у С++.

Абстракции над железом-то? Да, верно. В том-то и проблема.

ГВ>> А если называть вещи своими именами — то ещё и не догнали.
VD>Ну, это если совсем уж потерять связь с рельностью.

Виртуальной? Ну может быть.

Если да, то скажи — с какой именно? А то их много тут развелось.

ГВ>> Вот когда я смогу гладко вписать в C# (а равно и в Java) регистровую модель процессора — вот там и поговорим.
VD>Да нет смысла в 21 веке вообще говорить о регистрах и процессоре. 21 век — век абстракции. А процессоры и их регистры — это удел тех немногих кто пишит оптимизирующие компиляторы и имподобные вещи, а так же драйверы (хотя там уже не факт).

Однако — приходится. И с этим уже ничего не поделаешь.

VD>Миф о тормознутости дотета или явы устаривает с каждым годом. Они и сейчас не уступают многим компиляторам. А завтра вообще превзойдут всех их из-за возможности динамической оптимзации.

Знаешь, в чём проблема Java на самом деле? Не в плохом оптимизаторе, а в мифе, что "... больше не ресурс" и "в 21 веке ...". И эти два мифа напрочь срезают весь хот-спот. Отказаться от этих мифов — потерять преимущества Java. Не отказываться — потерять в скорости продукта. Может быть и не так резко, но примерно так.

ГВ>>...Выводы, как грится, делайте сами. Для ленивых выскажу кое-какие из своих.
VD>Так и что твой рассказ то доказывает? Что медленную реализацию можно ускорить? Или ты считашь что доказал несостоятельность Явы таким макаром?

Главный вывод — что Java способствует мифотворчеству о возможности игнорирования физики компьютеров. Спору нет, это всё возможно — но только до определённых пределов.

ГВ>>1. Java — неплохое средство (не скрою — во многом она мне нравится своей стройностью), но увы. С управлением памятью всё пока ещё не слишком гладко.
VD>Да все там ОК с памятью. Просто думать нужно как эффективнее алгоритмы делать. Единственное что в Яве с памятью не здорово, так это отсуствие структур. А так...

Правильно, Влад. Думать. А это становится принято всё менее и менее. Не в Java, естественно, дело, а в прокладке. А прокладка формируется в том числе и инструментом. Т.е. — языком прорамирования. Чуешь, к чему клоню?

VD>Сдается мне, что вера в скорость плюсов тебя подводит.

Да какая ещё "вера"? Реальность, дружище. Реальность в виде микросекунд и мегабайтов. И наблюдения за оной с линейкой и секундомером.

VD>Разбираться нужно или достконально, или вообще не разбираться. На уровен "вот одна реализация работает лучше другой на другом языке" можно наделать любых выводов. С Явой я особо не работаю. Знаю ее по тестам. Но скажу, что она медленнее дотнета всего чуть, чуть. А дотнет мало чем уступает тому же 6-ому VC. Так что если хочешь доказать обратно, то приводи конкретный код и тесты. Поглядим... сравним... поправим и перемерим.

Ну так встань, да посмотри...

Если не путаю — www.log4j.apache.org и www.log4cpp.apache.org. Кроме того, ИМХО, log4j вполне даже показательный пример. Apache foundation, как-никак, почти наверняка много неглупого народу руки приложило.

Всё — чин-чинарём.

ГВ>> Как следствие того, что имеются:
ГВ>>а) небесконеченость конкретного компьютера;
VD>Серьезный аргумент. Я его даже не понял.

Да не, всё в порядке. INFINITE_LOOP.Duration == 7 seconds. Memory is infinite. Sky is blue. Go to sleep, everything is all right.

ГВ>>б) модель уважаемого Фон-Нефймана, которая, к сожалению — рулит;
VD>О! Еще белее серьезный аргумент. Жаль связь не просматривается.

Ну как. У нас есть один процессор. Есть ограниченное количество памяти. Есть долговременное хранилище. Добавим, что есть пространство адресов процессора и т.д, и т.п. Впрочем — да, INFINITE рулит, я и забыл.

Даже синхронизация кэшей процессоров — так, чушь на ровном месте.

ГВ>>в) необходимость культуры програмирования компьютеров на том же C++. А не вой относительно "ОО — рулез форева" или "темплейты — рулез там же".
VD>Ну, культура она конечно и производительность поднимает и сложность задачи понижает. Вот только почему-то код на плюсах особо быстрее от этого не становится, и глюки в нем так тоннами и остаются. Как не спросишь С++-программиста, так у него ошибок нет. Это все у других. А как запустишь какую С++-программку так она все глючит и глючит.

Ещё раз. Я не знаю причин по которым log4j обладает той архитекторой, которой обладает. Возможно, что архитектуру можно было сделать другой. Выбрали ту, что выбрали. Но её аналог на C++ даже с учётом того, что там фигачатся std::string по значению и сплошняком virtual — практически вдвое быстрее.

Да, кстати, о глюках речи и не было. Любая программа может глючить. RSDN@Home тоже глючит, но тем не менее мне вот он нравится.

ГВ>>А потом уже — тесты на шустрость. И вот тут поглядим: кто — кого, откуда, куда, почему и откуда издержки.
VD>Да мы уже поглядели. Да не раз. И что-то никак не разглядим. А вот упрощение и ускорение разработки видно довольно четко.

Если ты сделал что-то быстро, но плохо, то люди быстро забудут о том, что ты сделал это быстро, но будут помнить о том, что это было плохо. А если сделал хорошо, но медленно — люди тоже забудут о том, что ты сделал медлено, но будут помнить о том, что это было — хорошо. (c) пословица.

... << RSDN@Home 1.1.3 stable >>

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

ГВ>> Вот когда я смогу гладко вписать в C# (а равно и в Java) регистровую модель процессора — вот там и поговорим.

VD>Да нет смысла в 21 веке вообще говорить о регистрах и процессоре. 21 век — век абстракции. А процессоры и их регистры — это удел тех немногих кто пишит оптимизирующие компиляторы и имподобные вещи, а так же драйверы (хотя там уже не факт).

Внесу свои пять копеек. Забудем о регистрах, тем более, что я и сам стараюсь никогда не опускаться до такого уровня. Программист, использующий .NET или Java, существенно зависит от разработчика соответствующего Framework`а, потому что без него родимого вы практически ничего сделать не сможете. Сложность нестандартной задачи — задачи, не решаемой напрямую или косвенно фраймоворком, возрастает многократно. Скажем, если в том же .NET`е не реализована какая-нибудь функциональность операционной системы, вам приходится решать совершенно отвлечённые задачи: куда в вашу иерархию классов встроить класс, на который будут мапироваться нативные вызовы к операционной системе, какие именно функции ОС вам придётся импортить, выполнить импорт этих функций и при этом не ошибиться при декларации их параметров и наконец отладить всё это... Может быть со временем вся винда будет на .NET и в MSDN`е описание функций будет приводиться для C# (хотя я в это не верю), но до тех пор увы...

VD>Миф о тормознутости дотета или явы устаривает с каждым годом. Они и сейчас не уступают многим компиляторам. А завтра вообще превзойдут всех их из-за возможности динамической оптимзации.

Всё это домыслы. Вот если вы напишете какой-нибудь реальный проект в 2-ух экземплярах на 2-ух языках, на плюсах и шарпе, вот только тогда можно будет говорить о сравнении производительности. Тесты ничего не показывают, я видел кучу тестов, которые показывают что Java медленнее плюсов и такое же количество, демонстрирующих обратное. С помощью тестов можно на заказ продемонстрировать и достоинства и недостатки.
Кстати, ответьте мне вот на какой вопрос. Почему-то когда говорят о том, что динамическая оптимизации может существенно увеличить быстродействие программы, написанной на шарпе, по сравнению с плюсами, забывают о нижеследующей вещи. Код нативных программ мапируется в память непосредственно из своего файла, следовательно процедура выгрузки страниц кода, при нехватке памяти, не будет приводить к операциям чтения/записи с винчестера. Нативный код, получаемый из байт-кода JIT`ом, будет располагаться в общей памяти и следовательно при необходимости выгрузки страниц, они будут явно выгружаться в страничный файл, что будет сопровождаться активными операциями чтения/записи данных с жёсткого диска. При большом размере программы, это может свести на нет всю динамическую оптимизацию... Или я где-то ошибаюсь, или кое-кто умалчивает об этой "возможности".

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

ГВ>Хммм... так. Сейчас как раз этим примерно и занимаюсь. Возможно, что я и ошибаюсь. Во всяком случае — кое что для солярки по части манагёра памятей я уже делал. Ты, кстати, какую версию Solaris имеешь ввиду? И какой компилятор? GCC или Forte? И кстати — что-то я не помню проблем при передаче std::string из одного .so в другой...
С сошками другая проблема. Если хочешь могу по почте рассказать о истории пререхода с gcc на Sun C++. Про прыжки вокруг двух STL'ей
в Sun C++ и строк в gcc. Здесь это уже офтопиком будет.

AC>>Таки Альксандреску вбивает читателям именно эту идею. Не надо забывать, что шаблоны (статическая параметризация) это ОДИН из МНОЖЕСТВА вариантов решения задачи, не единственный и не всегда самый лучший.
ГВ>ИМХО, он вбивает чертовски правильную идею: "Товарищи! Переносите контроль на компилятор, а не на тестеров!" И только-то... Что
Хм, тоесть ты хочешь сказать, что параметризация шаблона стратегией боле типоустойчива, чем параметризация конструктора обьекта интерфейсом стратегии? Задачу динамического конструирования или оптимизации через инлайнинг не рассматривает, рассматриваем именно типоустойчевость. Типоустойчевость вообще очень интересное понятие.... о нем долго можно говорить. То о чем ты говоришь, это проблемы студентов которые пошли в индустрию

Которые, кстати, очень часто вспоминают перечисленных авторов, по поводу и без.

ГВ>Да, кстати, а Алексндреску-то тут при чём?
На него чаще всего ссылаются, причем не на то, что он придумал и/или развил, а на то, что 'круто' изложил.

И иcходя из твоих слов, если я не согласен, что его идеи 100% истина, я плохой программер.

С этого топик и начинался.

ГВ>PS. Кстати, ты уж прости, но всё-таки — пробовал. Не сочти за наезд, но это тот случай, когда я готов получить свой законный moderatorial "+".

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

AC>>>Александреску и Маерс это плохие специалисты, я про то, что их книги это популизация методик
K>>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг.
K>>А вот Саттера и Мейерса очень рекомендую.
K>>Именно как популизацию грамотного стиля и методик программирования на C++.

Ш>Все трое -- ламеры.

Один ты — крутой кулхацкер?

VD>Но только переходя обратно понимашь, что нехватает уже не мелких фич языка, а некого ощущения "работы с песней"

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

И понимаешь, насколько нам эта песня "строить и жить помогает"

... << RSDN@Home 1.1.4 beta 2 rev. 0>>

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

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

J>>Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

Ш>Не судьба мне у тебя работать.

Ну, если ты предпочитаешь писать свои велосипеды — да.

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

WH>Ну там тоже есть приятные библиотеки. Например boost/preprocessor иногда очень полезна и ее использование вобщем ни чего не стоит.

Хотя мне и нравится буст, не удержусь от подколки.
Результат препроцессирования

#include <boost/preprocessor.hpp>

— это 85 тысяч строк (большей частью — пустые), файл размером 295 килобайт, если оставлять #line, или 170 килобайт, если не оставлять.

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

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

JJ>>И все потому, что в той фирме как раз и сидят такие люди, которых жутко прет писать свои классы, а гемор, который потом придется разгребать пользователям их чудо-класса — это уже не их дело, даже наоборот — пока есть баги, нужна их поддержка, т.е. к ним приедет еще бабла, и т.д., и т.п.
AC>Что-то мне подсказывает, что STL и BOOST там не помогут, хотя возможно я и ошибаюсь

ошибаешься

а по поводу многопоточности и прочего — так проект так до сих пор и сидит в прошлом веке, потому что эти самые третьесторонние велосипеды и не думали ничего поддерживать и об этом задумываться.
Это при том, что существует не одна реализация STL, тот же упомянутый Sun C++ с какой-то версии идет с STLPort, и если есть бага в одной — заюзай другую, благо они нормально поддерживаются.

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

Кто там что говорил о типобезопасности?
Шаблонов в этой велотеке нет — все на макросах.
Что ты там говорил о хипе?
В контейнерах нашей велотеки можно хранить только указатели — угадай, где приходится размещать объекты, и сколько гемора потом с очисткой памяти. И это практически делает невозможным использование исключений. Что у нас от С++ в итоге осталось?

Еще нужны аргументы?

P.S. А рядом сидит проект, написанный с нуля на STL — и они горя не знают, и у них на марше и многопоточность, и многопроцессорность, и исключения, и все прочие радости жизни, и горя они с STL (STLPort) не знают. При том, что пишут они высокопроизводительный сервер.

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

ГВ>>>Правильно, потому что ответом на "новое направление" часто может быть только новая группа шаблонов. Чего шум-то поднимать?

К>>Этак можно всё вообще свести к макросам. Например, базовые библиотеки TurboPascal 5.5 кто-нибудь видел? ООП на макроассемблере...
ГВ>Э, не путай калий с кальцием. Шаблоны и макросы — не одно и то же. Хм. Кодт, это я тебе рассказываю или у тебя дубль появился?

Не, я не путаю, а гиперболизирую.
Разумеется, С++ достаточно силён, чтобы выразить разнообразные вещи. Но цена будет разная. Местами — катастрофическая.

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

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

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

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

J>Здравствуйте, Alexey Chen, Вы писали:
J>а по поводу многопоточности и прочего — так проект так до сих пор и сидит в прошлом веке, потому что эти самые третьесторонние велосипеды и не думали ничего поддерживать и об этом задумываться.
Удивительно как люди разделяют эпохи — до STL и после STL, другого не дано в принципе. Эта ограниченость мышления тоже ведь последствие безальтернативного наследия популистов

J>Это при том, что существует не одна реализация STL, тот же упомянутый Sun C++ с какой-то версии идет с STLPort, и если есть бага в одной — заюзай другую, благо они нормально поддерживаются.
И обе в чем-то криво, каждая в своем. Это не предположение, это факт.

J>Что ты там говорил о хипе?
J>В контейнерах нашей велотеки можно хранить только указатели — угадай, где приходится размещать объекты, и сколько гемора потом с очисткой памяти. И это практически делает невозможным использование исключений. Что у нас от С++ в итоге осталось?
Я вообще-то конкретный пример привел, а ты как обычно скатился в общности.... сувать STL, как и буст во все щели не есть верное решение.
В своем рвении твой подход мало отличается от подхода людей писавших ту лбу, это просто другая крайность.

J>Еще нужны аргументы?
ИМХО, это не аргументы, это эмоции по поводу того как все плохо. Впрочем, мой топик тоже эмоции

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

J>>>Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

Ш>>Не судьба мне у тебя работать.

J>Ну, если ты предпочитаешь писать свои велосипеды — да.

Может STL конечно и супер. Но вот класс списка в ней воистину отстойный. И класс string тоже. Про iostream можно не говорить — это только для hello word годится. Двумерного массива в СТЛ нет видимо из за того что не вписывается в концепцию итераторов. И вообще хорошо бы ей всю кровь сменить и все органы пересадить, тогда авось и выйдет че-нить путное.

А пока велосипеды будут жить, плодится и процветать.

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

J>А я вот вспоминаю свои собственные впечатления, когда в однострочной формуле из квантовой механики разбираешься месяц.
Ну ты крут! Мало кто может за месяц понять сакральный смысл E=Hф

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Щас я обьясню сакральный смысл. Сакральный смысл состоит в том что:
1) сначала смотришь на формулу и ломаешь голову что же это такое?
2) месяц разбираешься что же это такое
3) когда разобрался думаешь, а зачем разбирался? что получил?

Т.е. в итоге имеешь геморой вначале, геморой в середине, геморой в конце. Вот такой сакральный смысл.

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

VD>Все нижесказанное мое личное мнение:

VD> и на сегодня С++ не отвечает современным требованиям рынка.

А в чем конкретно не отвечает не мог бы рассказать подробнее?

VD> Шарп/дотнет и Ява уже отъели немалый кусок рынка у С++ и отъедание продолжается. Если С++ не будет развиваться дальше, то все Бусты и Алексондреску ему не помогут.

Что значит развиваться дальше и в каких различных направлениях?

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

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

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

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

J>>Здравствуйте, Alexey Chen, Вы писали:
J>>а по поводу многопоточности и прочего — так проект так до сих пор и сидит в прошлом веке, потому что эти самые третьесторонние велосипеды и не думали ничего поддерживать и об этом задумываться.
AC>Удивительно как люди разделяют эпохи — до STL и после STL, другого не дано в принципе. Эта ограниченость мышления тоже ведь последствие безальтернативного наследия популистов :)

ну почему же
STL не появилсь на пустом месте, были же общепризнанные библиотеки от Rogue Wave, например

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

J>>Это при том, что существует не одна реализация STL, тот же упомянутый Sun C++ с какой-то версии идет с STLPort, и если есть бага в одной — заюзай другую, благо они нормально поддерживаются.
AC>И обе в чем-то криво, каждая в своем. Это не предположение, это факт.
охотно верю.
Только вот пользователей (и, соответственно, тестеров) любой "всеобщей" библиотеки типа STL, причем доступной в исходниках, ибо шаблоны, и ее конкретных инкарнаций типа STLPort на порядки больше, чем может теоретически быть у пользователей любого самописного велосипеда, особенно если он поставляется еще и без исходников.
Соответственно чисто статистически надежность ее выше, особенно при том, что библиотека постоянно обновляется (вон, даже Павел Кузнецов туда чего-то закинул).

J>>Что ты там говорил о хипе?
J>>В контейнерах нашей велотеки можно хранить только указатели — угадай, где приходится размещать объекты, и сколько гемора потом с очисткой памяти. И это практически делает невозможным использование исключений. Что у нас от С++ в итоге осталось?
AC>Я вообще-то конкретный пример привел, а ты как обычно скатился в общности.... сувать STL, как и буст во все щели не есть верное решение.

Я же в самом начале сказал, что работаю (сам, лично) в таком проекте. Конкретика хуже некуда :(

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

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

J>>Еще нужны аргументы?
AC>ИМХО, это не аргументы, это эмоции по поводу того как все плохо. Впрочем, мой топик тоже эмоции :)

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

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

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

К>Есть же ряд вещей, которые удобнее, будучи свойствами языка, а не извращениями библиотек.
К>Примеры — лямбда-исчисление, развитое RTTI, мультиметоды несчастные...

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

И потом, а кто мешает развивать си++? Берешь, дополняешь язык новыми конструкциями, делаешь компилятор и пускаешь его в свободное плавание. Вопрос только в том, приживется ли такой язык или нет. Если кто помнит, параллельно со Страустром было несколько проектов ОО си языка. Но си++ люди приняли, а другие никто и не помнит. Вот реализация языка и есть реальный способ проверить, действительно ли твое понимание "развития" си++ совпадает с реальностью или нет.

Здесь еще вопрос, стоит ли вообще дополнять си++ новыми синтаксическими конструкциями или нет. На самом деле, язык уже очень сложен, и такое добавление его только еще больше усложнит. Может быть поэтому, начиная с определенного момента, перестали пополнять си++ новыми конструкциями и обратились к расширению библиотек?

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

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

[]

ГВ>Ну я, разумеется, бардак почуял, ковырять пальцем в носе не стал, да и накатал свой. Так... по-быстрому. С внутренними издержками ~3 микросекунды (опять-таки, важно соотношение — ~1:6 по отношению к log4cpp). Функциональность — та же. Т.е. — конфигурирование и т.п. На C++, разумеется. Само собой — свои схемы управления памятью и параметризацией логгирования. Кстати — и то и то с привлечением темплейтов и у-у-ужасного пугала — множественного наследования. Ну ещё немного здоровой програмистской наглости и игнорирования авторитетов ОО (впрочем, это у меня уже давно "на автомате"). Потратил я на это, чтобы тебе не соврать, примерно 2 дня, работая "с пятого на десятое", т.е., не особо вдаваясь в детали оптимизации и высокого штиля софтостроения. Но не скажу, что решено всё было тривиально — уж извините, мы не из этой группы детского сада.

А поглядеть можно?

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

ГВ>Если ты сделал что-то быстро, но плохо, то люди быстро забудут о том, что ты сделал это быстро, но будут помнить о том, что это было плохо. А если сделал хорошо, но медленно — люди тоже забудут о том, что ты сделал медлено, но будут помнить о том, что это было — хорошо. (c) пословица.

(c) Королев С.П.
http://www.rtc.ru/encyk/bibl/golovanov/korolev/52.html

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

AC>Угу, компонентная архитектура маст дай? Что, обычный полиморфизм скончался от старости и теперь в ходу только статический, а прогу мы перекомпиливаем каждый раз полностью и по новой? Таки Альксандреску вбивает читателям именно эту идею. Не надо забывать, что шаблоны (статическая параметризация) это ОДИН из МНОЖЕСТВА вариантов решения задачи, не единственный и не всегда самый лучший.

Да нет там этого ничего блин

Не вбивает он там никакие идеи — он просто приводит примеры (одни из множества возможных) того, как могут а не должны или иные задачи.

AC>Нет не смешно, мне грустно, поскольку эту книгу превозносят как символ кул-программинга. О чем собственно и топик.

Да не привозносят ее. Просто это действиетльено книга с примера, которые н обязательно слепо использовать все и целиком. Это книга для того, чтобы почерпнуть некоторые общие идеи и мысли, очень полезные кстати.

ГВ>>А точнее можно? Ты всех полпулистов не любишь или только С++-ных?
AC>Ну еще проповедников не люблю, эффект очень похожий.

AC>А рамках разных или в рамках команды? Я понимаю что многие верят, что использовать тяжёлый трактор в котором без механика не разберешся, когда нужен именно велосипед, это круто! Только не понимаю почему.

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

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

AC>Хм, STL... переезд с одной версии копилятора на другую, резкое падение производительности.... предолжения?
AC>Основных причины было две, по другому реализованы алокаторы и list имел линейную сложность для size().

Ну про сложность различных операций и алгоритмов в STL прекрасно написано английским по белому в документации.

В том числе и про list::size().
Обращаю внимание — написано в документации, т.е. в стандарте языка. У многих ли велосипедов вообще есть документация?
А с такими подробностями?
Есть небольшой тест — сколько программистов в проекте должен переехать грузовик, чтобы проект встал раком на энное время?
С велосипедами обычно достаточно переехать одного программиста, чтобы проект встал надолго, примеры долго искать не надо...

AC>Про std::string на нескольких процессорах вспоминать будем?

А вот это конкретный косяк реализации строк в конкретной реализации STL. Наоптимизировались, copy-on-write устроили.
Мало того, с вероятностью близкой к единице везде, где есть такие оптимизации, будут проблемы (и с производительностью тоже).

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

Тут надо не забывать, что:
1) не всегда просад есть
2) даже когда он есть, он может вообще не влиять ни на что
Если же вилы — то оптимизируем. Причем тут еще думать надо, лечить ли следствие или причину.

--
Vitaly Belekhov

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

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

J>>А я вот вспоминаю свои собственные впечатления, когда в однострочной формуле из квантовой механики разбираешься месяц.
S>Ну ты крут! Мало кто может за месяц понять сакральный смысл E=Hф ;)

Если помнишь, сие уравнение и все члены, в него входящие — комплекснозначные.
Добавь в уравнение нестационарный член, попробуй раскрутить потом все это по квазиклассике — сразу можно вспомнить про многолистные функции (помнишь ТФКП?) и над этим помедитировать с годик. А то и с десяток.

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

J>Если помнишь, сие уравнение и все члены, в него входящие — комплекснозначные.
J>Добавь в уравнение нестационарный член, попробуй раскрутить потом все это по квазиклассике — сразу можно вспомнить про многолистные функции (помнишь ТФКП?) и над этим помедитировать с годик. А то и с десяток.

Офф: кто-нибудь, можете поделиться ссылочкой на тему "волосы экспоненты". Помню, что было что-то очень математически красивое, да конспекты по ТФКП не сохранил.

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

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

AC>>Хм, STL... переезд с одной версии копилятора на другую, резкое падение производительности.... предолжения?
AC>>Основных причины было две, по другому реализованы алокаторы и list имел линейную сложность для size().
VVB>Ну про сложность различных операций и алгоритмов в STL прекрасно написано английским по белому в документации.

VVB>В том числе и про list::size().
Ссылочку в стандарте пожалуйста. Или ты про доку к конкретному STL'ю? Дык мы вроде говорим о том, что оно везде одинаково работает

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

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

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

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

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

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

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

Сюда посмотри, это как пример о стереотипе. http://www.rsdn.ru/Forum/Message.aspx?mid=836687&only=1

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

MN>Внесу свои пять копеек. Забудем о регистрах, тем более, что я и сам стараюсь никогда не опускаться до такого уровня. Программист, использующий .NET или Java, существенно зависит от разработчика соответствующего Framework`а, потому что без него родимого вы практически ничего сделать не сможете. Сложность нестандартной задачи — задачи, не решаемой напрямую или косвенно фраймоворком, возрастает многократно.

Эээ... А что, на С++ не та же фигня?
Программист на С++ не зависит от того же STL?

... << RSDN@Home 1.1.3 stable >>

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

_>Здравствуйте, Mr. None, Вы писали:

MN>>Внесу свои пять копеек. Забудем о регистрах, тем более, что я и сам стараюсь никогда не опускаться до такого уровня. Программист, использующий .NET или Java, существенно зависит от разработчика соответствующего Framework`а, потому что без него родимого вы практически ничего сделать не сможете. Сложность нестандартной задачи — задачи, не решаемой напрямую или косвенно фраймоворком, возрастает многократно.

_>Эээ... А что, на С++ не та же фигня?
_>Программист на С++ не зависит от того же STL?

Спроси себя — могу ли я на плюсах писать без STL?
Конечно да.
А могу ли я написать класс джавовский без фреймворка?
Конечно нет.

Конечно некоторая аналогия есть в ситуациях, но очень хлипкая, имхо

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

AC>Сюда посмотри, это как пример о стереотипе. http://www.rsdn.ru/Forum/Message.aspx?mid=836687&only=1

Ну так я не понял в чем соль? Человек говорит тебе, что есть библиотеки — продуманные и вылизанные, гарантирующие отсутствие ошибок и гарантирующие определенные возможности — почему не пользовать их? Давай пример попроще приведу. Есть функция синуса, вшитая в язык. Почему ты не пишешь свою, если так не доверяешь библиотекам? или ты признаешь только голый язык — типа грамматика + компилятор и никакие библиотеки тебе не нужны?
Ты ж пойми — о бусте говорят как о стандарте де-факто не потому что это модно, а потому что он вобрал в себя кучу типовых решений, так же как это сделала стл к примеру. А стандартизация таких вещей как буст и стл приведет только к повышению их качества, потому что там в комитете очень нехилые перцы рубятся за каждую фичу языка. Так что ты зря волнуешся — с надежностью там все пучком

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

К>>Благодаря этому вовсю живёт Fortran. Правда, F-90 уже больше напоминает VB6, но старообрядцы до сих пор могут насладиться его подмножеством (!) F-IV.

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

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

M>И потом, а кто мешает развивать си++? Берешь, дополняешь язык новыми конструкциями, делаешь компилятор и пускаешь его в свободное плавание. Вопрос только в том, приживется ли такой язык или нет. Если кто помнит, параллельно со Страустром было несколько проектов ОО си языка. Но си++ люди приняли, а другие никто и не помнит.
На самом деле, распространенность и "признание" во-многом зависят от двух вещей: реклама; персональный компьютер.
Кто знал о пакале до турбо-паскаля? Персоналки сыграли свою решающую роль. Ну и реализация удачная была. Но самое главное — цена!!!!!!! 49.50 $
Сам язык играет гораздо меньшую роль, чем его реализация и маркетинг.
Языки Вирта тому пример — посчле паскаля он создал еще 2: Модула и Оберон. И что?
M>Здесь еще вопрос, стоит ли вообще дополнять си++ новыми синтаксическими конструкциями или нет. На самом деле, язык уже очень сложен, и такое добавление его только еще больше усложнит. Может быть поэтому, начиная с определенного момента, перестали пополнять си++ новыми конструкциями и обратились к расширению библиотек?

M>Вопрос на самом деле стоит так: каждый ли программист (человек) может (должен?) изучить си++ или для кого-то это невозможно ввиду его ограниченых способностей?
На моей кафедре — обязательный язык. А способностей не хватает — в продавцы компьютеров!

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

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

J>>Если помнишь, сие уравнение и все члены, в него входящие — комплекснозначные.
J>>Добавь в уравнение нестационарный член, попробуй раскрутить потом все это по квазиклассике — сразу можно вспомнить про многолистные функции (помнишь ТФКП?) и над этим помедитировать с годик. А то и с десяток.

К>Офф: кто-нибудь, можете поделиться ссылочкой на тему "волосы экспоненты". Помню, что было что-то очень математически красивое, да конспекты по ТФКП не сохранил.
Да ладно мужики, выпендриваться

Я из NARG помню только одно слово "вычет" (абсолютно забыв при этом, что оно означает — и не надо мне объяснять, все равно тут же забуду, уже сознательно)

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

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

SK>>Думаю, что никак. Людей, которые обожают C++ для всего (т.е. говорят, что это универсальный современный язык, а не низкоуровневое средство), на мой взгляд, можно вполне назвать синтаксическими онанистами (только не бейте

).

ГВ>Ударим железным кулаком синтаксического онанизма по компонентной проституции!

Не народ, не понимаете вы ничего в сексуальной ориентации

Это правильно называется "синтаксический мазохизм"!

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

LVV>Кто знал о пакале до турбо-паскаля?

Паскаль был весьма и весьма известен.

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

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

P>А поглядеть можно?

Нельзя, поскольку это решение заменило log4cpp.

Но принципы могу раскрыть поподробнее.

... << RSDN@Home 1.1.3 stable >>

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

S>(c) Королев С.П.
S>http://www.rtc.ru/encyk/bibl/golovanov/korolev/52.html

О! Спасибо!

... << RSDN@Home 1.1.3 stable >>

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

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

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

J>>>Если помнишь, сие уравнение и все члены, в него входящие — комплекснозначные.
J>>>Добавь в уравнение нестационарный член, попробуй раскрутить потом все это по квазиклассике — сразу можно вспомнить про многолистные функции (помнишь ТФКП?) и над этим помедитировать с годик. А то и с десяток.

К>>Офф: кто-нибудь, можете поделиться ссылочкой на тему "волосы экспоненты". Помню, что было что-то очень математически красивое, да конспекты по ТФКП не сохранил.
LVV>Да ладно мужики, выпендриваться

LVV>Я из NARG помню только одно слово "вычет" (абсолютно забыв при этом, что оно означает — и не надо мне объяснять, все равно тут же забуду, уже сознательно)
LVV>

что тут выпендриваться — я чуть диссер на эту тему не написал

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

К>>>Офф: кто-нибудь, можете поделиться ссылочкой на тему "волосы экспоненты". Помню, что было что-то очень математически красивое, да конспекты по ТФКП не сохранил.
LVV>>Да ладно мужики, выпендриваться

LVV>>Я из NARG помню только одно слово "вычет" (абсолютно забыв при этом, что оно означает — и не надо мне объяснять, все равно тут же забуду, уже сознательно)
LVV>>

J>что тут выпендриваться — я чуть диссер на эту тему не написал

Про волосы или про вычеты? Если про волосы — то хотя бы скажи, куда искать. Гугл мне не помог.

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

LVV>На самом деле, распространенность и "признание" во-многом зависят от двух вещей: реклама; персональный компьютер.
LVV>Кто знал о пакале до турбо-паскаля? Персоналки сыграли свою решающую роль. Ну и реализация удачная была. Но самое главное — цена!!!!!!! 49.50 $
Хммм... 1987 или 1988 г., ЕС-1035, СВМ, R-PASCAL — курсовики точно на нём писали.

Потом, AFAIK, в успехе турбо-паскаля основную роль сыграла интегрированная среда. А реклама была что-то там на одну страницу BYTE. Хотя, может быть, это я какую-то легенду Борландовскую пересказываю.

LVV>Сам язык играет гораздо меньшую роль, чем его реализация и маркетинг.
Так вроде бы C++ — то без особого маркетинга распространился. Вот что интересно...

... << RSDN@Home 1.1.3 stable >>

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

AC>>Сюда посмотри, это как пример о стереотипе. http://www.rsdn.ru/Forum/Message.aspx?mid=836687&only=1

G>Ну так я не понял в чем соль? Человек говорит тебе, что есть библиотеки — продуманные и вылизанные, гарантирующие отсутствие ошибок и гарантирующие определенные возможности — почему не пользовать их?
Нет, он говорил о том, что некие люди пишут плохой код, но если бы они использовали STL/BOOST то всем было бы счастье... но как я уже говорил в других топиках, до первого столба. Почему он так думает я не знаю. Но он ведь не только так думает, а считает что это ЕДИНСТВЕННО ПРАВИЛЬНОЕ мнение. Если мение не правильное смотри пункт первый

Чем подкреплено это мнение? Сравнением удачного и не удачного проекта? И только. Я вот знаю обратную картину. Какой можно сделать вывод? Дело не в STL'е или BOOST'е, а в людях. Меня же интересовало почему эти самые люди думают иначе. На что мне отвечают, что дык, правильно думают, по той причине что смотрите ... дальше идет текст приведенного топика.

G>Давай пример попроще приведу. Есть функция синуса, вшитая в язык. Почему ты не пишешь свою, если так не доверяешь библиотекам? или ты признаешь только голый язык — типа грамматика + компилятор и никакие библиотеки тебе не нужны?
Наверное по тому, что реализация синуса меня устраивает, а вот когда мене для задачи не устраивает функция генерации случайных чисел я пушу свою.

G>Ты ж пойми — о бусте говорят как о стандарте де-факто не потому что это модно, а потому что он вобрал в себя кучу типовых решений, так же как это сделала стл к примеру.
Которые в большенстве своем решают выдуманные проблемы, а те, что решают типовые? могут быть реализованы существенно проще и гораздо прозрачнее.

Ладно фиг с ним, с бустом. У нас есть много универсальных контейнеров, которым даже можно определить свои алокаторы и отношения порядка, но весь код работающий с этими контейнерами, (!) должен быть шаблонным. Иначе он будет работать только с конетенером имеющим конкретный аллокатор и конкретное оношение упорядочения. Круто, да? Тоесть функция которой надо взять из хеша/мапа/листа/... значение, должна знать, как контенер распределяет память и вычисляет ключи... мега дизайн!!!! А если мы вдруг соберем один модуль с одним STL'ем, а другой с другим... баах!!! Странно а компилер вроде один, и конструкции тоже. Вот я и не понимаю почему это правильно? А мне, я так полагаю, нужно этим пользоваться, ибо это единственно верный путь для профессионального программиста.

Мы вроде как не про программеров-любителей говорим, правильно? Как алгоритмы работают занем, как тесткейсы писать тоже. И опыт некоторый имеется. Вот у меня и возникает вопрос, что мне дают контейнеры STL'я, кроме гемороя с его кривой (сорри, специфической) архитектурой? Ответ — стандартность, причем мнимую. Только стандартность, но ни как не стабильность, переносимость, производительность. А если еще и BOOST будет двать стандартность ...

У нас в команде есть подобные классы, оттестированные на классе решаемых ими задач. Совершенно детерминированные на тех платформах с которыми мы работаем. Но почему-то когда я пользую их, кулл программеры, разбрасывают пальцы веером и говорят — уууу... ламер, БЮСТА не тебя нет! А в приведенном, как пример, топике, человек четко говорит — УВОЛЬНЯТЬ! Вот это промывка мозгов, это я понимаю!!!

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

J>Удивительно, что люди, зная о существовании нормальных оттестированных библиотек, пишут свои велосипеды, которые дай бог чтобы на 30% покрывали возможности этих библиотек и давали хотя бы 40% их устойчивости, и кричат на всех углах, что они круче всех. И их крикам верят все, кроме несчастных пользователей их велосипедов.
Может они пишут эти вилосипеды, чтобы те покрывали нужды именно этих людей а не решали некие абстрактные проблемы

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

J>Здравствуйте, Шахтер, Вы писали:

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

J>>>Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

Ш>>Не судьба мне у тебя работать.

J>Ну, если ты предпочитаешь писать свои велосипеды — да.

Не угадал. Я пишу реактивные самолёты. А велосипеды -- это то, на чем вы ездеете.

... << RSDN@Home 1.1.0 stable >>

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

K>Здравствуйте, Шахтер, Вы писали:

K>>>А зачем писать своё если есть готовое проверенное решение
Ш>>НЕТ решения, в этом всё и дело.
K>ЕСТЬ

НЕТ.

Ш>>Большинство проблем, которые решает boost -- надуманные.

K>ну вот что я использую из boost в текущем проекте:
K>1. boost::lexical_cast
K>использую, потому что lexical_cast удобно использовать в шаблонном коде
K>и он бросает исключение в случае неудачи. То есть это то что мне нужно.
K>Там примерно такой код
K>

K>template<typename T>
K>void parser::parse_value(T& value)
K>{
K>  if (m_tok.next())
K>  {
K>    tokenizer::token tk = m_tok.current_token();

K>    value = boost::lexical_cast<T>(std::string(tk.ptr, tk.len));
K>  }
K>}
K>

Про lexical_cast я на форуме писал -- использовать это чудо не стоит.

K>2. boost::numeric_cast
K>сейчас я работаю со старым проектом.
K>там много вычислений, а так же много преобразований из целых в вещественные и обратно.
K>старый код менять не стал, потому что работает и слава богу
K>в местах числовых преобразований вставил numeric_cast,
K>чтоб потом не мучиться и не искать ошибку из-за обрезания числа.

Не знаком.

K>3. boost::shared_ptr
K>4. boost::scoped_ptr
K>5. stl::auto_ptr
K>не хочу думать об освобождении памяти, ну и в случае исключения всё почистится

Эти вещи юзабельные. Хотя по-хорошему, счетчики ссылок должны быть интруизивными.

K>6. boost::bind
K>удобно

Если ты злоупотребляешь функторами -- тогда да.

K>-------------------------------------------------------------------------

K>>>shared_ptr в несколько строк не напишешь, это очень мощная штука.
Ш>>Это очень злементарная штука.
K>а элементарная штука не может быть мощной?

Может.

K>-------------------------------------------------------------------------

K>>>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг.
K>>>А вот Саттера и Мейерса очень рекомендую.

Ш>>Все трое -- ламеры.
K>ну вы хоть согласны, что среди ламеров они всё таки не самые ламеристые?

Конечно, без сомнения.

... << RSDN@Home 1.1.0 stable >>

А зря.

... << RSDN@Home 1.1.0 stable >>

LVV>>>Я из NARG помню только одно слово "вычет" (абсолютно забыв при этом, что оно означает — и не надо мне объяснять, все равно тут же забуду, уже сознательно)
LVV>>>

J>>что тут выпендриваться — я чуть диссер на эту тему не написал

К>Про волосы или про вычеты? Если про волосы — то хотя бы скажи, куда искать. Гугл мне не помог.

Честно говоря -- первый раз слышу. На что оно хотя бы похоже?

... << RSDN@Home 1.1.0 stable >>

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

_>Здравствуйте, Mr. None, Вы писали:

MN>>Внесу свои пять копеек. Забудем о регистрах, тем более, что я и сам стараюсь никогда не опускаться до такого уровня. Программист, использующий .NET или Java, существенно зависит от разработчика соответствующего Framework`а, потому что без него родимого вы практически ничего сделать не сможете. Сложность нестандартной задачи — задачи, не решаемой напрямую или косвенно фраймоворком, возрастает многократно.

_>Эээ... А что, на С++ не та же фигня?
_>Программист на С++ не зависит от того же STL?

Если зависит, то это уже не программист, а наркоман.

... << RSDN@Home 1.1.0 stable >>

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

S>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Если ты сделал что-то быстро, но плохо, то люди быстро забудут о том, что ты сделал это быстро, но будут помнить о том, что это было плохо. А если сделал хорошо, но медленно — люди тоже забудут о том, что ты сделал медлено, но будут помнить о том, что это было — хорошо. (c) пословица.

S>(c) Королев С.П.
S>http://www.rtc.ru/encyk/bibl/golovanov/korolev/52.html

Цитата.

Адскую по объему работу предстояло провести с новой ракетой баллистикам ОКБ: Святославу Сергеевичу Лаврову, Рефату Фазыловичу Аппазову, Михаилу Сергеевичу Флорианскому и другим. Борцы с "тлетворной буржуазной идеологией" позаботились о том, чтобы к этому времени у нас в стране существовала единственная (!) счетная машина — БЭСМ — "чудо техники". Если она работала четыре минуты подряд и не ломалась — это расценивалось как подарок судьбы! 476
Баллистики приезжали ночью, считали и были счастливы, потому что несколько минут работы этих загадочных шкафов равнялись многонедельному труду девчонок-расчетчиц, которые с утра до вечера трещали в Подлипках на своих допотопных, еще из Германии привезенных "Рейнметаллах", "Мерседесах" и уж совсем никуда не годных "Феликсах".

Я плакал.

... << RSDN@Home 1.1.0 stable >>

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

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

LVV>>На самом деле, распространенность и "признание" во-многом зависят от двух вещей: реклама; персональный компьютер.
LVV>>Кто знал о пакале до турбо-паскаля? Персоналки сыграли свою решающую роль. Ну и реализация удачная была. Но самое главное — цена!!!!!!! 49.50 $
ГВ>Хммм... 1987 или 1988 г., ЕС-1035, СВМ, R-PASCAL — курсовики точно на нём писали.

ГВ>Потом, AFAIK, в успехе турбо-паскаля основную роль сыграла интегрированная среда. А реклама была что-то там на одну страницу BYTE. Хотя, может быть, это я какую-то легенду Борландовскую пересказываю.

LVV>>Сам язык играет гораздо меньшую роль, чем его реализация и маркетинг.
ГВ>Так вроде бы C++ — то без особого маркетинга распространился. Вот что интересно...

Ничего странного. Он пришелся по душе профи, которые в ту пору ещё не были вытеснены ваятелями формочек.

... << RSDN@Home 1.1.0 stable >>

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

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

J>>Здравствуйте, Шахтер, Вы писали:

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

J>>>>Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

Ш>>>Не судьба мне у тебя работать.

J>>Ну, если ты предпочитаешь писать свои велосипеды — да.

Ш>Не угадал. Я пишу реактивные самолёты. А велосипеды -- это то, на чем вы ездеете.

то, на чем мы в настоящее время ездим (если ты читал внимательно мой пост) — это даже не самокат, скорее, конь на палочке

хотя народ, его написавший, наверняка уверен, что это как минимум МИГ-25

Шахтер, если ты действительно пишешь вещи, намного превосходящие STL и boost по всем параметрам — выкладывай их в исходники, или закинь в тот же boost.
Давайте сделаем настоящие реактивные самолеты стандартом, чтобы никаким жаверам и шарперам даже и в голову не приходило сравнивать свои языки с С++.

Мы ведь тут для обмена опытом собрались, а не просто друг перед другом пальцы покидать, ведь так?

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

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

[]

ГВ>Нельзя, поскольку это решение заменило log4cpp.

Но принципы могу раскрыть поподробнее.

Было бы очень интересно. Собираюсь передывать то, что есть сейчас, так что любые идеи пойдут.

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

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

AC>>>Сюда посмотри, это как пример о стереотипе. http://www.rsdn.ru/Forum/Message.aspx?mid=836687&only=1

Я встряну, с Вашего позволения, раз уж мои слова обсуждаются

G>>Ну так я не понял в чем соль? Человек говорит тебе, что есть библиотеки — продуманные и вылизанные, гарантирующие отсутствие ошибок и гарантирующие определенные возможности — почему не пользовать их?
AC>Нет, он говорил о том, что некие люди пишут плохой код, но если бы они использовали STL/BOOST то всем было бы счастье... но как я уже говорил в других топиках, до первого столба. Почему он так думает я не знаю. Но он ведь не только так думает, а считает что это ЕДИНСТВЕННО ПРАВИЛЬНОЕ мнение. Если мение не правильное смотри пункт первый :) Чем подкреплено это мнение? Сравнением удачного и не удачного проекта? И только. Я вот знаю обратную картину. Какой можно сделать вывод? Дело не в STL'е или BOOST'е, а в людях. Меня же интересовало почему эти самые люди думают иначе. На что мне отвечают, что дык, правильно думают, по той причине что смотрите ... дальше идет текст приведенного топика.

вот именно что дело в людях.
И если я пользуюсь STL или boost или RWTools или Tools++ или еще чем-то общеизвестным, то я всегда могу поконтактировать с производителем, пообщаться с пользователями библиотеки, потому что имя им — легион, я могу посмотреть в исходники библиотеки и разобраться, как она работает, а в случае стандартной STL именно благодаря ее стандартности я могу еще и просто сменить реализацию, если какая-то конкретная меня в чем-то не устраивает, ибо интерфейс STL остается тем же.
В случае же велосипедов, написанных конкретными людьми, у меня такой возможности нет: люди (те самые "некие") в этой фирме давно уже не работают, исходный код недоступен, сменить библиотеку никакой возможности нет (вернее, есть, но ценой переписывания всего проекта).

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

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

G>>Давай пример попроще приведу. Есть функция синуса, вшитая в язык. Почему ты не пишешь свою, если так не доверяешь библиотекам? или ты признаешь только голый язык — типа грамматика + компилятор и никакие библиотеки тебе не нужны?
AC>Наверное по тому, что реализация синуса меня устраивает, а вот когда мене для задачи не устраивает функция генерации случайных чисел я пушу свою.

такое действительно бывает — все проекты разные, в каждом есть хоть какая-то изюмнка

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

G>>Ты ж пойми — о бусте говорят как о стандарте де-факто не потому что это модно, а потому что он вобрал в себя кучу типовых решений, так же как это сделала стл к примеру.
AC>Которые в большенстве своем решают выдуманные проблемы, а те, что решают типовые? могут быть реализованы существенно проще и гораздо прозрачнее.

чем не устраивают бустовские xxx_ptr, bind, checked_delete, xxx_traits и прочая?
или они решают выдуманные проблемы?
согласен, в бусте есть сырые куски, так их никто и не стандартизирует пока — посмотри на сайте wg21, что реально собираются стандартизировать.

AC>Ладно фиг с ним, с бустом. У нас есть много универсальных контейнеров, которым даже можно определить свои алокаторы и отношения порядка, но весь код работающий с этими контейнерами, (!) должен быть шаблонным. Иначе он будет работать только с конетенером имеющим конкретный аллокатор и конкретное оношение упорядочения. Круто, да? Тоесть функция которой надо взять из хеша/мапа/листа/... значение, должна знать, как контенер распределяет память и вычисляет ключи... мега дизайн!!!! А если мы вдруг соберем один модуль с одним STL'ем, а другой с другим... баах!!! Странно а компилер вроде один, и конструкции тоже. Вот я и не понимаю почему это правильно? А мне, я так полагаю, нужно этим пользоваться, ибо это единственно верный путь для профессионального программиста.:)

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

AC>Мы вроде как не про программеров-любителей говорим, правильно? Как алгоритмы работают занем, как тесткейсы писать тоже. И опыт некоторый имеется. Вот у меня и возникает вопрос, что мне дают контейнеры STL'я, кроме гемороя с его кривой (сорри, специфической) архитектурой? Ответ — стандартность, причем мнимую. Только стандартность, но ни как не стабильность, переносимость, производительность. А если еще и BOOST будет двать стандартность ...

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

AC>У нас в команде есть подобные классы, оттестированные на классе решаемых ими задач. Совершенно детерминированные на тех платформах с которыми мы работаем. Но почему-то когда я пользую их, кулл программеры, разбрасывают пальцы веером и говорят — уууу... ламер, БЮСТА не тебя нет! А в приведенном, как пример, топике, человек четко говорит — УВОЛЬНЯТЬ! Вот это промывка мозгов, это я понимаю!!! :)

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

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

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

К>>>>Офф: кто-нибудь, можете поделиться ссылочкой на тему "волосы экспоненты". Помню, что было что-то очень математически красивое, да конспекты по ТФКП не сохранил.
LVV>>>Да ладно мужики, выпендриваться :)
LVV>>>Я из NARG помню только одно слово "вычет" (абсолютно забыв при этом, что оно означает — и не надо мне объяснять, все равно тут же забуду, уже сознательно)
LVV>>> :) :) :)

J>>что тут выпендриваться — я чуть диссер на эту тему не написал :)

К>Про волосы или про вычеты? Если про волосы — то хотя бы скажи, куда искать. Гугл мне не помог.

Про многозначные решения нестационарного уравнения Шредингера.

Про волосы — покопаюсь с своих конспектах по ТФКП, но вряд ли сегодня-завтра :)
Но раз гугл не помог — наверное, ты что-то перепутал, потому что кое-какие лекции по ТФКП в сети лежат

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

J>вот именно что дело в людях.
J>И если я пользуюсь STL или boost или RWTools или Tools++ или еще чем-то общеизвестным, то я всегда могу поконтактировать с
производителем, пообщаться с пользователями библиотеки, потому что имя им — легион, я могу посмотреть в исходники библиотеки и разобраться, как она работает, а в случае стандартной STL именно благодаря ее стандартности я могу еще и просто сменить реализацию, если какая-то конкретная меня в чем-то не устраивает, ибо интерфейс STL остается тем же.
Перечисленное тобой означает, что за данный код не отвечает ни кто, и каждый может сделать что он хочет. С кем именно ты бдешь контактировать, к примеру, из тех кто прикручивал к Sun C++ STLport, и будут ли они контактировать с тобой и на сколько хорошо..
Это бедь бизнес. Это может быть выгодно или нет... А денежки то текут и работу делать тем немениее надо.

J>В случае же велосипедов, написанных конкретными людьми, у меня такой возможности нет: люди (те самые "некие") в этой фирме давно уже не работают, исходный код недоступен, сменить библиотеку никакой возможности нет (вернее, есть, но ценой переписывания всего проекта).
Интересно. Откуда ты взял, что собственны код команды не доступен внутри команды, при этом обязательно не оттестирован и криво написан?

J>Ты, безусловно, считаешь себя очень крутым программером,

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

J>Ни один велосипед не сравнится в этом смысле с общими библиотеками.
Да что вы говорите!? Общие библиотеки решают конкретные задачи плохо по определению и пользуются ими по причине низкой стоимости переиспользования. Я же имею множество примеров когда стоимось переиспользования (в том числе саппорта) дороже стоимости разработки.

J>Так вот если проект написан на общедоступной библиотеке — ты вообще можешь в любой момент разогнать всю свою команду и набрать людей с улицы, просто знающих эту библиотеку — и они в первый же день смогут начать писать код.
У меня вот есть совершенно конкретный вопрос, если вдруг ты словишь ошибку второго или третьего рода где-то в глубине буста, что будешь делать? Вешаться? Или быстренько раскидаешь буст, поймешь что к чему и пойдешь искать причину? Дык,это как-то не сочитается с 'набрать новых людей'... таких спецов ооооочень мало.

J>У нас же в проекте (да и в любом проекте, использующим велосипеды) пара месяцев уходит только на то, чтобы человек просто въехал в библиотеку, сценарии ее использования, основные баги и объездные пути.
А в тех что используют STL, BOOST, и т.д. такого нет? Что-то вы путаете уважаемый.

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

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

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

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

G>>>Ты ж пойми — о бусте говорят как о стандарте де-факто не потому что это модно, а потому что он вобрал в себя кучу типовых решений, так же как это сделала стл к примеру.
AC>>Которые в большенстве своем решают выдуманные проблемы, а те, что решают типовые? могут быть реализованы существенно проще и гораздо прозрачнее.

J>чем не устраивают бустовские xxx_ptr, bind, checked_delete, xxx_traits и прочая?
Тем, что они мне НЕ НУЖНЫ. Тем, что в том виде в котором мне нужна ПОДОБНАЯ ФУНКЦИОНАЛЬНОСТЬ они монструозны, трудно понимаемы и несопровождаемы. Однако мнение о том, что это де-фато стандарт, предпологает, что их ДОЛЖЕН знать и пользовать КАЖДЫЙ. Бред какой-то.

AC>>Ладно фиг с ним, с бустом. У нас есть много универсальных контейнеров, которым даже можно определить свои алокаторы и отношения порядка, но весь код работающий с этими контейнерами, (!) должен быть шаблонным. Иначе он будет работать только с конетенером имеющим конкретный аллокатор и конкретное оношение упорядочения. Круто, да? Тоесть функция которой надо взять из хеша/мапа/листа/... значение, должна знать, как контенер распределяет память и вычисляет ключи... мега дизайн!!!! А если мы вдруг соберем один модуль с одним STL'ем, а другой с другим... баах!!! Странно а компилер вроде один, и конструкции тоже. Вот я и не понимаю почему это правильно? А мне, я так полагаю, нужно этим пользоваться, ибо это единственно верный путь для профессионального программиста.

J>а по поводу аллокаторов — я не очень понял, почему весь код должен быть шаблонным — у меня написана куча нешаблонного кода, который отлично работает с любыми STL.

Обясню. У тебя есть функция которая, например, работает со строками, но в конкретном случае тебе для оптимизации узкого места, пришлось сменить аллокатор, и что же мы видим? А видим мы, что готовую функцию мы уже испоьзовать не можем. Вот мне и интересно зачем утильной функции зависить еще и от распределителя памяти окромя интерфейса обьекта. Это совсем простой пример

J>Да, конечно, его надо будет перекомпилировать, но, во-первых, шаблонный код уж тем более придется перекомпилировать, а во-вторых, я не знаю самоубийц, которые при смене библиотеки (даже просто версии), используемой в проекте, не перекомпилировали бы весь проект целиком.
А если проект состоит из модулей которые завият только по интерфейсам и пишутся разными командами, только одна использует MS STL, а другая STL port? И находятся вообще в разных городах и конторах? А вроде стандартная либа

J>про тесткейсы, которые тестируют и покрывают всю функциональность — вот этих сказок я уже наелся по самое не хочу.
Ну если для вас это сказки, а не инструмент, тогда звиняте...
Кстати, что вы подразумевали под 'всю'? У конкретного утильного класса должна быть очень узкая функциональность, опять же по определению, хотя смотря на буст, мне кажется, что народ считает это плохой практикой.

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

К>>Про волосы или про вычеты? Если про волосы — то хотя бы скажи, куда искать. Гугл мне не помог.

Ш>Честно говоря -- первый раз слышу. На что оно хотя бы похоже?

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

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

AC>Нет, он говорил о том, что некие люди пишут плохой код, но если бы они использовали STL/BOOST то всем было бы счастье... но как я уже говорил в других топиках, до первого столба. Почему он так думает я не знаю. Но он ведь не только так думает, а считает что это ЕДИНСТВЕННО ПРАВИЛЬНОЕ мнение. Если мение не правильное смотри пункт первый

Чем подкреплено это мнение? Сравнением удачного и не удачного проекта? И только. Я вот знаю обратную картину. Какой можно сделать вывод? Дело не в STL'е или BOOST'е, а в людях. Меня же интересовало почему эти самые люди думают иначе. На что мне отвечают, что дык, правильно думают, по той причине что смотрите ... дальше идет текст приведенного топика.

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

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

Чем не устраивает реализация вектора в стл?

G>>Ты ж пойми — о бусте говорят как о стандарте де-факто не потому что это модно, а потому что он вобрал в себя кучу типовых решений, так же как это сделала стл к примеру.
AC>Которые в большенстве своем решают выдуманные проблемы, а те, что решают типовые? могут быть реализованы существенно проще и гораздо прозрачнее.

Пальцем ткнуть в выдуманную проблему

AC>Ладно фиг с ним, с бустом. У нас есть много универсальных контейнеров, которым даже можно определить свои алокаторы и отношения порядка, но весь код работающий с этими контейнерами, (!) должен быть шаблонным. Иначе он будет работать только с конетенером имеющим конкретный аллокатор и конкретное оношение упорядочения. Круто, да? Тоесть функция которой надо взять из хеша/мапа/листа/... значение, должна знать, как контенер распределяет память и вычисляет ключи... мега дизайн!!!! А если мы вдруг соберем один модуль с одним STL'ем, а другой с другим... баах!!! Странно а компилер вроде один, и конструкции тоже. Вот я и не понимаю почему это правильно? А мне, я так полагаю, нужно этим пользоваться, ибо это единственно верный путь для профессионального программиста.

Какой-то бред

Не нужно тебе думать о том как контейнер распределяет память — он это сделает без тебя.

AC>Мы вроде как не про программеров-любителей говорим, правильно? Как алгоритмы работают занем, как тесткейсы писать тоже. И опыт некоторый имеется. Вот у меня и возникает вопрос, что мне дают контейнеры STL'я, кроме гемороя с его кривой (сорри, специфической) архитектурой? Ответ — стандартность, причем мнимую. Только стандартность, но ни как не стабильность, переносимость, производительность. А если еще и BOOST будет двать стандартность ...

А, то есть вот в чем ключ — просто не рубишь архитектуру либы? Тогда понятно откуда вопросы

AC>У нас в команде есть подобные классы, оттестированные на классе решаемых ими задач. Совершенно детерминированные на тех платформах с которыми мы работаем. Но почему-то когда я пользую их, кулл программеры, разбрасывают пальцы веером и говорят — уууу... ламер, БЮСТА не тебя нет! А в приведенном, как пример, топике, человек четко говорит — УВОЛЬНЯТЬ! Вот это промывка мозгов, это я понимаю!!!

раскидывание пальцев это проблема кул программеров. А насчет буста может они и правы — ты бы посмотрел туда может и увидел что то что вытам всей командой тестили и вылизывали уже давно оттестировано и вылизано за вас.

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

) я бы призадумался о его проф пригодности.

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

AC>Интересно. Откуда ты взял, что собственны код команды не доступен внутри команды, при этом обязательно не оттестирован и криво написан?

Команда поехала на рыбалку и разбилась на автобусе — нужно нанимать новых. Сколько времени уйдет у низ на то чтобы охватить все тонкости вашей внутренней библиотеки?

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

бывает хороший код — стл например

AC>Да что вы говорите!? Общие библиотеки решают конкретные задачи плохо по определению и пользуются ими по причине низкой стоимости переиспользования. Я же имею множество примеров когда стоимось переиспользования (в том числе саппорта) дороже стоимости разработки.

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

AC>У меня вот есть совершенно конкретный вопрос, если вдруг ты словишь ошибку второго или третьего рода где-то в глубине буста, что будешь делать? Вешаться? Или быстренько раскидаешь буст, поймешь что к чему и пойдешь искать причину? Дык,это как-то не сочитается с 'набрать новых людей'... таких спецов ооооочень мало.

Легко. Человек, знающий С++, гарантированно разберется в бусте. там нет никакой мегаэкзотики, недоступной неопсвященным. Так же как и стл. Просто открой код и посмотри. Это все не названо нашими именами только потому что мы родились поже

AC>А в тех что используют STL, BOOST, и т.д. такого нет? Что-то вы путаете уважаемый.

Каанечно нет. Зачем разбираться в стл если ты его и так знаешь

AC>Вопрос о преемуществах очень сложен

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

кретерии: доступность информации, распространность, наличие поддержка
и поясни относительно выделенного что имелось в виду напримере стл, а то че-то какая-то демагогия.

AC>

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

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

J>>чем не устраивают бустовские xxx_ptr, bind, checked_delete, xxx_traits и прочая?
AC>Тем, что они мне НЕ НУЖНЫ. Тем, что в том виде в котором мне нужна ПОДОБНАЯ ФУНКЦИОНАЛЬНОСТЬ они монструозны, трудно понимаемы и несопровождаемы. Однако мнение о том, что это де-фато стандарт, предпологает, что их ДОЛЖЕН знать и пользовать КАЖДЫЙ. Бред какой-то.

То что ты их не можешь опнять не делает их плохими

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

AC>Обясню. У тебя есть функция которая, например, работает со строками, но в конкретном случае тебе для оптимизации узкого места, пришлось сменить аллокатор, и что же мы видим? А видим мы, что готовую функцию мы уже испоьзовать не можем. Вот мне и интересно зачем утильной функции зависить еще и от распределителя памяти окромя интерфейса обьекта. Это совсем простой пример

Так может проблема в том аллокаторе который ты подсунул, то ест ькак ты сказал в людях?

AC>А если проект состоит из модулей которые завият только по интерфейсам и пишутся разными командами, только одна использует MS STL, а другая STL port? И находятся вообще в разных городах и конторах? А вроде стандартная либа

ну так пересобирели только исправленный модуль — в чем проблемато?

AC>Ну если для вас это сказки, а не инструмент, тогда звиняте...
AC>Кстати, что вы подразумевали под 'всю'? У конкретного утильного класса должна быть очень узкая функциональность, опять же по определению, хотя смотря на буст, мне кажется, что народ считает это плохой практикой.

пальцем ткнуть в буст где размазана функциональность

Здравствуйте!

Если я правильно понял, то обсуждение идет о том, можно ли считать того, кто не использует библиотеки STL, boost и т.п., профессиональным программистом. Или скажем мягче. Что правильней? Использовать библиотеки или писать свои реализации необходимой функциональности. Тогда лучше сначала определиться, в какой области программирования лучше использовать сторонний код, а в какой писать код самому. А то получится, что с одной стороны сидит писатель драйверов, а с другой пользовательского интерфейса и спорят, что лучше C или C#.

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

V>Если я правильно понял, то обсуждение идет о том, можно ли считать того, кто не использует библиотеки STL, boost и т.п., профессиональным программистом. Или скажем мягче. Что правильней? Использовать библиотеки или писать свои реализации необходимой функциональности.

В частности это. Или лучше сказать — в основном это, плюс причины почему это так.

V>Тогда лучше сначала определиться, в какой области программирования лучше использовать сторонний код, а в какой писать код самому. А то получится, что с одной стороны сидит писатель драйверов, а с другой пользовательского интерфейса и спорят, что лучше C или C#.

Не знаю, может быть. Но я, например, пишу и драйвера, и крупный серверный софт, и мелкую шаровару, и везде использую, как STL (это ведь не только контейнеры), так и свои классы. Бывает прада на C пишу, но это уже другая история. Вот меня и удивляет жёсткая позиция некоторых товарищей, с аргументацией построенной на предположениях и мифах. Причем с уклоном: чем сложнее и мощнее решение — тем лучше!

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

G>То что ты их не можешь опнять не делает их плохими

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

G>У тебя ваще очень хорошия стиль — выдвигаем неверное утверждение от лица оппонента и с блеском опровергаем его.
Дык мне его навязывают.

Извиняюсь, конечно, не в данном треде, здесь приемущественно к STL'ю привязать пытаются.

AC>>Обясню. У тебя есть функция которая, например, работает со строками, но в конкретном случае тебе для оптимизации узкого места, пришлось сменить аллокатор, и что же мы видим? А видим мы, что готовую функцию мы уже испоьзовать не можем. Вот мне и интересно зачем утильной функции зависить еще и от распределителя памяти окромя интерфейса обьекта. Это совсем простой пример

G>Так может проблема в том аллокаторе который ты подсунул, то ест ькак ты сказал в людях?

Что-то у меня последнее время создается впечатление, что знатоки STL'я, которые упрекают меня в том, что я его не знаю, совсем не понимают его проблем. Видимо сказывается стереотип мышления вбитый в мозги поп-изданиями и крутыми авторами. Ладно дальше пытаться не буду.. те кто могут думать не только так, как завещал великий отец, думаю, уже поняли о чем я говорил.

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

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

G>>Так может проблема в том аллокаторе который ты подсунул, то ест ькак ты сказал в людях?

AC>Что-то у меня последнее время создается впечатление, что знатоки STL'я, которые упрекают меня в том, что я его не знаю, совсем не понимают его проблем. Видимо сказывается стереотип мышления вбитый в мозги поп-изданиями и крутыми авторами. Ладно дальше пытаться не буду.. те кто могут думать не только так, как завещал великий отец, думаю, уже поняли о чем я говорил.

Я извиняюсь нижайше за грубость, но: пукнул и в кусты чтоли?
Если честно я так и не понял, чтож ты так плачешь из-за STL (может конечно не такой кулхацкер как ты и мысли читать не умею

) — если есть аргументы, то объясни их по-человечески, а нечего тут пустой флейм разводить.
Диспут должен быть подтверждён фактами, имхо.

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

G>>>Так может проблема в том аллокаторе который ты подсунул, то ест ькак ты сказал в людях?
AC>>Что-то у меня последнее время создается впечатление, что знатоки STL'я, которые упрекают меня в том, что я его не знаю, совсем не понимают его проблем. Видимо сказывается стереотип мышления вбитый в мозги поп-изданиями и крутыми авторами. Ладно дальше пытаться не буду.. те кто могут думать не только так, как завещал великий отец, думаю, уже поняли о чем я говорил.

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

К>Если честно я так и не понял, чтож ты так плачешь из-за STL (может конечно не такой кулхацкер как ты и мысли читать не умею

) — если есть аргументы, то объясни их по-человечески, а нечего тут пустой флейм разводить.
К>Диспут должен быть подтверждён фактами, имхо.

Я не плачу, я хочу понять откуда такая жесткая вера в отцов.

Относитлеьно конкретно этой проблемы.

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

Теперь берём STL и наблюдаем интересное архитектурное решение при котором функция, работающая с контейнером, еще зависит и от того, как контейнер распределяет память, от того как считает ключи/порядок, ....

Понятно конечно ЗАЧЕМ так сделано, не понятно почему это БЕЗУСЛОВНО ПРАВИЛЬНО.

Я понятно выразился? Для вас такая структура стандартной библиотеки естественна? Для меня вот нет.

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

LVV>>Я из NARG помню только одно слово "вычет" (абсолютно забыв при этом, что оно означает — и не надо мне объяснять, все равно тут же забуду, уже сознательно)
LVV>>

Ш>А зря.
Каждому свое

Я предпочитаю в С++ копаться — интересно!
А ТФКП — ну не люблю я ето дело!

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

LCR>Хочу посмотреть, можно?
Чего посмотреть-то?

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

V>Здравствуйте!

V>Если я правильно понял, то обсуждение идет о том, можно ли считать того, кто не использует библиотеки STL, boost и т.п., профессиональным программистом. Или скажем мягче. Что правильней? Использовать библиотеки или писать свои реализации необходимой функциональности. Тогда лучше сначала определиться, в какой области программирования лучше использовать сторонний код, а в какой писать код самому. А то получится, что с одной стороны сидит писатель драйверов, а с другой пользовательского интерфейса и спорят, что лучше C или C#.

Скажем так — профессиональным програмистом можно считать любого, кто умеет составлять и формализовать алгоритмы. С++ или шарп или кобол — это просто средства формализации. Как говаривал мой препод в инстике "Я могу программировать находясь на расстоянии в 20 км от машины", и я думаю что он тыщу раз прав. Но опять же — тут речь идет о том что нам дают эти библиотеки ваще. Я утверждаю что с точки зрения ращзработчика они дают много, товарищ не согласен — вот мы и сцепились

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

AC>Не знаю, может быть. Но я, например, пишу и драйвера, и крупный серверный софт, и мелкую шаровару, и везде использую, как STL (это ведь не только контейнеры), так и свои классы. Бывает прада на C пишу, но это уже другая история. Вот меня и удивляет жёсткая позиция некоторых товарищей, с аргументацией построенной на предположениях и мифах. Причем с уклоном: чем сложнее и мощнее решение — тем лучше!

Человек, фразы про то что чем сложнее решеня тем лучше звучат только от тебя. С этого ты собственно и начал эту ветку. Покажи мне пальцем на сообщение, где говорилось бы о том что чем сложнее либа тем она лучше? Где тебе навязываются библиотеки итп? Ты тут воюешь с ветряными мельницами.

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

AC>Ну вот мы и вернулись к теме топика. А что если он способен понять буст и считает его монструозным? Получается — 'надо призадуматься над квалификацией'?

Ткнуть пальцем в монструозность буста, что непонятно-то? само собой, есть свои особенности ( я вот например далеко не все из него пользую, но кое-что полезное попадается ) ну так не нравится не пользуй их — тебя никто не заставляет

AC>Дык мне его навязывают.

Извиняюсь, конечно, не в данном треде, здесь приемущественно к STL'ю привязать пытаются.

Ты его сам навязал в самом первом своем посте. Типа "почему алекснадреску буст и стл (хороший коктейль) считается хорошим стилем и примером для подрадражания если это на самом деле такой отстой" — смысл изначального поста был примерно таким.

AC>Что-то у меня последнее время создается впечатление, что знатоки STL'я, которые упрекают меня в том, что я его не знаю, совсем не понимают его проблем. Видимо сказывается стереотип мышления вбитый в мозги поп-изданиями и крутыми авторами. Ладно дальше пытаться не буду.. те кто могут думать не только так, как завещал великий отец, думаю, уже поняли о чем я говорил.

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

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

почему это мы ее использовать не можем? давай конкретный пример. Или так просто ляпнул?

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

ГВ>>Нельзя, поскольку это решение заменило log4cpp.

Но принципы могу раскрыть поподробнее.

P>Было бы очень интересно. Собираюсь передывать то, что есть сейчас, так что любые идеи пойдут.

Отпиши мне на мыло в профайле.

... << RSDN@Home 1.1.3 stable >>

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

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

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

Эк каково загнул..внушаить, товарищ комисар

Мы в рабстве у оголтелых буржуазных популяризаторов стл. Кстати, а как тебе разделение до С++ и после С++? Тоже кстати были свои популяризаторы ООП.

AC>И обе в чем-то криво, каждая в своем. Это не предположение, это факт.

не бывает абсолютного идеала. однако стл как грится pretty fucking close

AC>Я вообще-то конкретный пример привел, а ты как обычно скатился в общности.... сувать STL, как и буст во все щели не есть верное решение.

дык кто же тебя заставляет. ясный перец — если тебе чтото не подходит в библиотеке — пиши свое. но я смотрю ты против библиотек ваще. даже против стандартных.

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

J>>Еще нужны аргументы?
AC>ИМХО, это не аргументы, это эмоции по поводу того как все плохо. Впрочем, мой топик тоже эмоции

эт без базара

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

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

читать майерса "Эффективное использование стл" совет 4.

AC>И тоже везде одинако работает?
AC>Я про то что C++ — это совсем не стандарт, а набор рекомендаций, и STL не везде и не всегда одинаково работает.

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

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

а кто кричит кроме тебя?

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

Вопрос — сколько времени убъет команда на создание и вылизывание своего аналога стл с нужными им функциональностями и особенностями?

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

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

_>>Здравствуйте, Mr. None, Вы писали:

MN>>>Внесу свои пять копеек. Забудем о регистрах, тем более, что я и сам стараюсь никогда не опускаться до такого уровня. Программист, использующий .NET или Java, существенно зависит от разработчика соответствующего Framework`а, потому что без него родимого вы практически ничего сделать не сможете. Сложность нестандартной задачи — задачи, не решаемой напрямую или косвенно фраймоворком, возрастает многократно.

_>>Эээ... А что, на С++ не та же фигня?
_>>Программист на С++ не зависит от того же STL?

Ш>Если зависит, то это уже не программист, а наркоман.

Ага, framework-addicted

... << RSDN@Home 1.1.3 stable >>

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

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

К>Спроси себя — могу ли я на плюсах писать без STL?
К>Конечно да.
К>А могу ли я написать класс джавовский без фреймворка?
К>Конечно нет.

Теоретически, конечно, да. А на практике? Что, на С++ мы все пишем с нуля?
Ни фига подобного. Используем и STL, и MFC, и WTL и кучу сторонних библиотек.
Так, простите, в чем же разница?

К>Конечно некоторая аналогия есть в ситуациях, но очень хлипкая, имхо

... << RSDN@Home 1.1.3 stable >>

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

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

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

К>>Спроси себя — могу ли я на плюсах писать без STL?
К>>Конечно да.
К>>А могу ли я написать класс джавовский без фреймворка?
К>>Конечно нет.

_>Теоретически, конечно, да. А на практике? Что, на С++ мы все пишем с нуля?
_>Ни фига подобного. Используем и STL, и MFC, и WTL и кучу сторонних библиотек.
_>Так, простите, в чем же разница?

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

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

LVV>>>Сам язык играет гораздо меньшую роль, чем его реализация и маркетинг.
ГВ>>Так вроде бы C++ — то без особого маркетинга распространился. Вот что интересно...

Ш>Ничего странного. Он пришелся по душе профи, которые в ту пору ещё не были вытеснены ваятелями формочек.

... << RSDN@Home 1.1.3 stable >>

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

G>>>>Так может проблема в том аллокаторе который ты подсунул, то ест ькак ты сказал в людях?
AC>>>Что-то у меня последнее время создается впечатление, что знатоки STL'я, которые упрекают меня в том, что я его не знаю, совсем не понимают его проблем. Видимо сказывается стереотип мышления вбитый в мозги поп-изданиями и крутыми авторами. Ладно дальше пытаться не буду.. те кто могут думать не только так, как завещал великий отец, думаю, уже поняли о чем я говорил.
К>>Я извиняюсь нижайше за грубость, но: пукнул и в кусты чтоли?
AC>Да ладно, я так понимаю это обычное явление на этом форуме. Наверное жжёт обьем накопленого опыта и знаний

Ничего, бывает.

К>>Если честно я так и не понял, чтож ты так плачешь из-за STL (может конечно не такой кулхацкер как ты и мысли читать не умею

) — если есть аргументы, то объясни их по-человечески, а нечего тут пустой флейм разводить.
К>>Диспут должен быть подтверждён фактами, имхо.
AC>Я не плачу, я хочу понять откуда такая жесткая вера в отцов.
Да никто в них не верит особо. Их привыкли противопоставлять очередным "магистралепрокладчикам" индустрии, которые открывают очередную лыжню в будущее.

AC>Относитлеьно конкретно этой проблемы.

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

AC>Теперь берём STL и наблюдаем интересное архитектурное решение при котором функция, работающая с контейнером, еще зависит и от того, как контейнер распределяет память, от того как считает ключи/порядок, ....
Значит ты не просёк главного: STL — это не фетиш. Видимо, тут проблема в другом — в стереотипе восприятия. Да, я понимаю, когда MS выпускает новую либу и та становится "промышленным стандартом" (подразумевается — средством решения всех проблем), то считается, что писать под эту либу — правильно. Куча менеджеров и "архитекторов" начинает раздувать щёки по поводу очередного прыжка в будущее через зловонную яму сложности и т.п. Можно запустить сертификацию по этой либе, можно вставить её название в резюме и т.п. Короче — фетиш он и есть фетиш.

Но вот проблема — если перенести такой же стереотип на использование STL, то полезут рога и копыта во все стороны. И это правильно. Поскольку STL — просто стандартная библиотека для C++, но отнюдь не "промышленный стандарт", т.е. — не панацея и таковой не прикидывается. Пойми, дружище, нечто "стандартное" — это вовсе не то, что должно решать все проблемы. Это просто нечто такое, о чём удалось договориться. А как правило, удаётся договориться о чём-то таком, что никому сильно не мешает, но кое-что, кое-где всем понемногу упрощает. Ну представь себе MFC в виде стандарта, принятого ISO!

Ды кто ж согласится-то на такое кроме самой MS?

С другой стороны, когда покрутишься в этом бардаке фетишизма, то поневоле приходишь к тому, что стоит вместо одного фетиша подсунуть другой, более "правильный". Это не всегда правильно, но иной раз срабатывает. Вот народ и начинает визжать, что "самое правильное — это STL" и т.п. Есть, конечно, и другие причины. Более того, они в каждом конкретном случае — свои. Но есть общая черта — поминать авторитетов к месту и не к месту. Но это уже к доктору.

В тових словах есть рациональные зёрна, но подумай — в каком контексте ты сам крутишься? И не провоцируешь ли чем-то других сам на такую контраргументацию, как ссылки на "отцов"?

AC>Понятно конечно ЗАЧЕМ так сделано, не понятно почему это БЕЗУСЛОВНО ПРАВИЛЬНО.
А никто так и не говорит. "БЕЗУСЛОВНО ПРАВИЛЬНО" — это какой-то психоз, что-ли.

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

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

Если тебе нужна полная независимость от реализации, то накрой контейнер интерфейсом — хоть с виртуальными функциями, хоть через JNI, хоть через COM. Зато в пределе, используя STL можно получить быстродействующую реализацию контейнера — правда, придётся ещё и аллокаторы перекрыть.

... << RSDN@Home 1.1.3 stable >>

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

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

Видимо поэтому и любят

мое мнение трезвое (?):

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

J>Здравствуйте, Шахтер, Вы писали:

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

J>>>Здравствуйте, Шахтер, Вы писали:

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

J>>>>>Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

Ш>>>>Не судьба мне у тебя работать.

J>>>Ну, если ты предпочитаешь писать свои велосипеды — да.

Ш>>Не угадал. Я пишу реактивные самолёты. А велосипеды -- это то, на чем вы ездеете.

J>то, на чем мы в настоящее время ездим (если ты читал внимательно мой пост) — это даже не самокат, скорее, конь на палочке

J>хотя народ, его написавший, наверняка уверен, что это как минимум МИГ-25

Сочуствую. Хотя эта ситуация для меня хорошо знакома.

J>Шахтер, если ты действительно пишешь вещи, намного превосходящие STL и boost по всем параметрам — выкладывай их в исходники, или закинь в тот же boost.

Сравнение не корректно. Я не пишу аналоги STL или boost. Я говорил о другом -- о качестве решений, не использующих эти библиотеки.

J>Давайте сделаем настоящие реактивные самолеты стандартом, чтобы никаким жаверам и шарперам даже и в голову не приходило сравнивать свои языки с С++.

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

J>Мы ведь тут для обмена опытом собрались, а не просто друг перед другом пальцы покидать, ведь так?

Ну, в данном форуме в основном кидают пальцы.

... << RSDN@Home 1.1.0 stable >>

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

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

... << RSDN@Home 1.1.0 stable >>

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

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

AC>>Я не плачу, я хочу понять откуда такая жесткая вера в отцов.
ГВ>Да никто в них не верит особо. Их привыкли противопоставлять очередным "магистралепрокладчикам" индустрии, которые открывают очередную лыжню в будущее.

ГВ>Значит ты не просёк главного: STL — это не фетиш. Видимо, тут проблема в другом — в стереотипе восприятия. Да, я понимаю, когда MS выпускает новую либу и та становится "промышленным стандартом" (подразумевается — средством решения всех проблем), то считается, что писать под эту либу — правильно. Куча менеджеров и "архитекторов" начинает раздувать щёки по поводу очередного прыжка в будущее через зловонную яму сложности и т.п. Можно запустить сертификацию по этой либе, можно вставить её название в резюме и т.п. Короче — фетиш он и есть фетиш.

Да просек, я все. Просто хотелось закинуть в форум мнение, что BOOST — это фетишь и посмотреть как на него прореагируют

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

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

.

Остальное же для большей амлтитуды. А уж сколько адреналина!!! Но, надеюсь, я смог подобрать аргументы близкие к реальным.

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

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

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

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

Пришлось радом хранить.

AC>>И тоже везде одинако работает?
AC>>Я про то что C++ — это совсем не стандарт, а набор рекомендаций, и STL не везде и не всегда одинаково работает.
И? Ты мне показал куда ссылатся на тему, что STL работает поразному, дык я это знаю.
Интересно вот что, чего это у нас стандарт то мозги компостирует? Можен он совсем не стандарт?
Может я его невнимательно смотрел и так где-то есть сносочка, что конкретно list может делать все что хочет.

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

G>Вопрос — сколько времени убъет команда на создание и вылизывание своего аналога стл с нужными им функциональностями и особенностями?
Конкретно по этому решению — ноль. И своего универсального класса списка там никто не писал, но и стандартные списки тоже не пользовали. Это конкретное решение конкретной задачи, в которой STL нафиг был не нужен. И заняло это чуть болше десятка строчек кода. Но мы же поступили неправильно, нам нужно было написать сруктурку в которой будет лежать кондишин, распределить ее на хипе, потому как она некопируемая, потом умным указателем зафигчить ее в лист, который тоже будет на хипе, затем по взрослому это дело юзать, на каждом контекст свиче. Я правильно понимаю?

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

__>>Фортран (насколько я знаю, общаясь с людьми, которые до сих пор предпочитают реализовывать алгоритмы на нем) живет за счет того, что несмотря на то, что его 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, норамльное стандартное средство. Я прикрасно понимаю, что значит стандартное, как и что именно я делаю когда я пишу его конструкции. Но вот часто стал замечать, как некоторые мои колеги/знакомые пользуют его на автомате как прочитали или где-то увидили. С одной стороны это хорошо, пишут однообразный (однотипный/шаблонный) хотя и не всегда понятный код, с другой плохо — они не задумываются что пишут и почему именно так. Как автоматы.

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

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, 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 строк — это достаточно большой класс.
Достаточно ли он оттестирован? Есть ли к нему юнит-тесты?

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

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

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

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

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

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

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

Я не про это

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

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

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

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

J>только это будет не С++-программер, а MFC-программер.
J>Потому что его нельзя будет использовать, например, в юниксовом проекте — там нету никакой MFC.
Почему тогда человек, знающий BOOST, но не знающий ACE, будет C++ программером, а не BOOST программером? Ведь его нельзя будет использовать на многих платформах на которых BOOST просто не живет.

Привет.

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

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

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

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

--
Vitaly Belekhov

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

J>>только это будет не С++-программер, а MFC-программер.
J>>Потому что его нельзя будет использовать, например, в юниксовом проекте — там нету никакой MFC.
AC>Почему тогда человек, знающий BOOST, но не знающий ACE, будет C++ программером, а не BOOST программером? Ведь его нельзя будет использовать на многих платформах на которых BOOST просто не живет.

ACE шагает по стране?

--
Vitaly Belekhov

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

VVB>ACE шагает по стране?

Типа того. Дурной пример, он как известно заразительный

. На моей памяти, он лет пять как шагает.

P.S.
Для тех, кто не в курсе что такое ACE (если таковые найдутся) http://www.cs.wustl.edu/~schmidt/ACE.html

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

AC>Дык, а зачем пытаться обьять необьятное? Особенность же 'наследует идеи STL' трудно назавать плюсом. Это именно особенность.
Основная идея STL кроется в ее первой букве — Standard. Это не особенность — это огромный плюс.

AC>Кстати, идеи STL местами тоже слишком универсальны... в результате чего, меня, например, иногда упрекают, что здесь вот, я типа не использовал STL, а писал свое. Как же так? А то, что свое везде работает одинаково [...]
Кто сказал, что работает одинаково? Есть ли тесты? Есть ли 10 млн. бетатестеров? Есть ли математическое обоснование эффективности? STL — стандартна, а если кто-то что-то там "написал свое", то сразу становиться вопрос — а что он там понаписал, почему он не использовал готовые решения, сколько ему на это потребовалось времени да и просто банальный: "Где деньги, Зин?", ведь экзерсисы ненавистника стандартов, мегабайт "чужого кода" да и вовсе мистеров "а-че-мне-boost-я-и-сам-так-могу" приходиться оплачивать. А потом оплачивать саппорт его кода, где в итоге не разберешься и с бутылкой.

AC> [...] как почему и сколько это будет стоить знать не надо, об этом уже подумали умные дяди.

Правда потом, ингода, в гости заходит мелкий пушной зверёк, и приходится разбираться, что же эти умные дяди такого напридумывали.
В случае boost'a можно спросить этих умных дядек или пару-тройку миллионов других умных дядек, а вот в слуае "суперкомпактного" (без мегабайт ненужных библиотек) "суперэффективного" (еще бы: контролировать ошибки и ловить исключения — это же так тормозит) кода Васи Пупкина спросить вообще не у кого, Вася в запое и отключил мобильник или вообще обиделся, что его затяжную гениальность не оценили и свалил.

К>>Про "конкретные и весьма не новые подходы" — огласите весь список пожалуйста.
AC>Ну, можно просто по конкретному примеру... вот совсем недвно, сделал я простинький колбэк, на что мне сказали, что я ламер, буст рулит, а Александреску давно придумал функтор

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

AC>И не всегда то, что он пишет хорошо подходит под задачи, о чем я кстати в его книге не видел ни слова.
Ну книги-то о другом

. Там же подходы описаны, а не готовые решения

.

AC>Если человек не спользует shared_ptr, а пишет свой класс в несколько строк, и не тянет за собой дцать метров сырков он ламер

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

AC>Если он не использует мега-bind и function, а стыдно сказать, пишет свой кусочек кода в несколько строк он недостоен быть C++ программером

Да, мода рулит! Собственно, об этом я говорил, а не о том что в C++ не нужны шаблоны.
Просто допустите мысль, что это не мода, а средство снижения издерждек в острой конкурентной борьбе, и на сегодняшний день — мера очень эффективная (может завтра это будет .NET, а может что-то еще). И будет вам счастье.

ИМХО, он однобок, крив и монструозен, но тем немение он достаточно 'полит корректен'.

AC>>Если он не использует мега-bind и function, а стыдно сказать, пишет свой кусочек кода в несколько строк он недостоен быть C++ программером

Да, мода рулит! Собственно, об этом я говорил, а не о том что в C++ не нужны шаблоны.
F>Просто допустите мысль, что это не мода, а средство снижения издерждек в острой конкурентной борьбе, и на сегодняшний день — мера очень эффективная (может завтра это будет .NET, а может что-то еще). И будет вам счастье.

Нет не допущу. И сделаю это аргументированно.
О чем вы хотели сказать? Что распределенее сложности между компонентами/библиотеками позволяет знать чтолько их интерфейсы и не греть мозги по их устройству. Это несомненно снижает издержки, и, как нестранно, требуемый уровень программистов. Все логично. И очень правильно по поводу Java или C# и вообще .NET языков. Но у native C++ есть маленькая особенность. Малюсенькая ошибка в коде, который пишет/сопровождает студент Вася Пупкин, может легко порушить мега-сложную либу, порушить так, что проект придется свернуть. Это я конечно утрирую, но думаю, идея о том, что использование внешнего сложного кода без понимания его работы (именно работы а не использования) именно в плюсах чревато крахом проекта. И я уверен что, 90% пользующих BOOST, да и STL тоже, не понимают как там все работает.

Для 'снижения издерждек в острой конкурентной борьбе' при отсутствии кадров, лучше использовать песочницы типа Java или .NET.

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

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

F>>Просто допустите мысль, что это не мода, а средство снижения издерждек в острой конкурентной борьбе, и на сегодняшний день — мера очень эффективная (может завтра это будет .NET, а может что-то еще). И будет вам счастье.

AC>Нет не допущу. И сделаю это аргументированно.
AC>О чем вы хотели сказать? Что распределенее сложности между компонентами/библиотеками позволяет знать чтолько их интерфейсы и не греть мозги по их устройству. Это несомненно снижает издержки, и, как нестранно, требуемый уровень программистов. Все логично. И очень правильно по поводу Java или C# и вообще .NET языков. Но у native C++ есть маленькая особенность. Малюсенькая ошибка в коде, который пишет/сопровождает студент Вася Пупкин, может легко порушить мега-сложную либу, порушить так, что проект придется свернуть. Это я конечно утрирую, но думаю, идея о том, что использование внешнего сложного кода без понимания его работы (именно работы а не использования) именно в плюсах чревато крахом проекта. И я уверен что, 90% пользующих BOOST, да и STL тоже, не понимают как там все работает.

AC>Для 'снижения издерждек в острой конкурентной борьбе' при отсутствии кадров, лучше использовать песочницы типа Java или .NET.

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

А про песочницы соглашусь, но STL это тоже отчасти "песочница".
А если наплевать на все песочницы, то почему бы на ассемблере проги не писать? Или, лучше, вообще в машинных кодах, зачем нам буквенное представление?
Утрирую, конечно

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

К>Здравствуйте, Alexey Chen, Вы писали:
К>Т.е. у тебя есть мегасложные проекты на несколько мегов сырцов, но которые ты в состоянии сам весь понять и легко найти баги? Так чтоли получается?
К>Тебе уже далеко не 1 человек тебе пишет, что экономически не обоснованно и нисколько не выгодно, в случае реально серьёзного приложения.
К>Конечно, если у тебя классов пара штук и строчек аля пару сотен (или даже тысяч), то, конечно, без проблем.
К>Но имхо речь идёт о системах посложнее, где надо учитывать гораздо больше рисков.

Мнея просто умиляют коменты с этого форума, в которых люди говорят про абстрактные сложные системы, в которых типа....
Да есть такие системы, всего я естественно в них не знаю, но багу (не из предметной области) найти смогу, и именно по причине отсутствия там сложных решений. B STL там используется и своие решения. А вот BOOST'а нет и не будет. Просто к сведенью, время создания утильных классов для таких систем несоизмеримо с реализацией предметной облости.

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

К>А про песочницы соглашусь, но STL это тоже отчасти "песочница".
К>А если наплевать на все песочницы, то почему бы на ассемблере проги не писать? Или, лучше, вообще в машинных кодах, зачем нам буквенное представление?
Я разве предлогал не сто-то наплевать? Я обратил внимание на специфику программирования на C++, про которую 'теоретики', очень часто забывают.

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

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

AC>>Дык, а зачем пытаться обьять необьятное? Особенность же 'наследует идеи STL' трудно назавать плюсом. Это именно особенность.
F>Основная идея STL кроется в ее первой букве — Standard. Это не особенность — это огромный плюс.
Если и плюс, то в кавычках.

Уже не раз писали, но ты видимо не заметил.
Стандартность STL не подразумевает оптимальности каждой из имплементаций.
Вот свежий пример: http://www.rsdn.ru/Forum/Message.aspx?mid=842375&only=1

Еще один пример — реализация std::list::size() в stlport как return distance(begin(),end());

std::string это вообще кусочек гемороя.
Хотя ярые stl-исты от него всячески отрекаются

Если всегда и везде использовать одну и ту же импелементацию
(это если повезёт и это возможно), то отсюда вопрос — а при чём тут stl?

Практика показывает, в большинстве конкретных случаев можно
написать более оптимальный по нужным параметрам (скорость<->место) контейнер/класс/алгоритм.
Мнение о сложности тестирования и потенциальной глючности считаю преувеличенным

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

Кстати, вопрос то оригинальный был больше про boost, чем про stl

Пока что я увидел только утверждения по поводу того,
что в бусте есть *_ptr, препроцессор (оспорено) и биндеры.

А нужен ли весь этот вагон кода, ради нескольких условно полезных вещей?

Про "полезность" буста, еще одна ссылочка вспомнилась: http://www.rsdn.ru/Forum/Message.aspx?mid=744672&only=1

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

VVB>>ACE шагает по стране?

AC>Типа того. Дурной пример, он как известно заразительный

. На моей памяти, он лет пять как шагает.

А в ACE-то ты что плохого видишь? Вполне себе приличная либа.

... << RSDN@Home 1.1.3 stable >>

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

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

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

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

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

По-моему, об этом в конечном итоге и идет речь. Как там, "тварь я дрожащая или право имею" (на творчество). Зарубим тупым предметом старушку STL!

... << RSDN@Home 1.1.0 stable >>

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

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

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

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

AC>>Я разве сказал лучше?

Я привел вполне себе аргумент.

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

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

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

Ты вот лучше объясни, почему я потроха STL знаю лучше, чем многие её адепты?

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

Да брось ты. Неужели осовение любого библа, хоть STL, хоть MFC, требует десятилетних усилий? А если так, то может это библо плохое?

... << RSDN@Home 1.1.0 stable >>

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

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

И теория примерно о том же говорит — "оставь мозги за воротами...". Ну и — ну их в одно место! Антон, не пугай народ.

Эдак мы докатимся до того, что помнить наизусть — лучше, чем понимать суть явлений.

P.S. Насколько я понял, ты сослался на практику менеджмента не иронии ради, а усиления аргументации для.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Геннадий Васильев, Вы писали:
VVB>>>ACE шагает по стране?

AC>>Типа того. Дурной пример, он как известно заразительный

. На моей памяти, он лет пять как шагает.
ГВ>А в ACE-то ты что плохого видишь? Вполне себе приличная либа.
Хм, вроде как я не сильно очепятываюсь, слова, вроде, вполне читаемые получаются

Где я сказал что она мне не нравиться? Или имелся в виду 'дурной пример', дык это я про то, что оно не BOOST и не STL и даже называется по другому.

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

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

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

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

Приведу пример, делаем сложный framework для бизнес програм, что сами разработали:

1. Протокол вызова удаленных процедур (аналог dcom);
Был вариант изначально использовать компоненты dcom, но как только поняли, что будем делать кросс-платформенный фреймворк, пришлость разрабатывать свою систему (какие-то левые порты dcom под линухами не катили, а corba нам идейно не подходила). Получилось даже очень и очень, не такое универсальное, как dcom, но очень производительное и кроссплатформеное.

2. Компонентную архитектуру;
Опять таки думали на com'е въехать.
3. Gui контроллы;
Та же опера, qt, wxwindows и еще какая-то кроссплатформенная лабудень нам не подходила (качеством)
... еще много чего, но там уже не изобретение колеса, а "больше"

Может я это всё привел не к месту, но например мы многое что изобрели (в том числе и велосипеды, но свои

), так как делаем как раз "собственные высокотехнологичные продукты".

p.s. а stl мы сами напильником заточили

... << RSDN@Home 1.1.3 stable >>

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

K>>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг.
K>>А вот Саттера и Мейерса очень рекомендую.
K>>Именно как популизацию грамотного стиля и методик программирования на C++.

Ш>Все трое -- ламеры.
А вот это мощно, я помню в своё время считал Вейерштрасса, Абеля, Коши просто м*даками

p.s. а ведь великие люди были.... чо то я бред понёс...

... << RSDN@Home 1.1.3 stable >>

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

S>p.s. а stl мы сами напильником заточили

Тоже метод. Не обязательно ведь переписывать на 100%. Можно выделить проблемные куски и довести их до ума.

... << RSDN@Home 1.1.0 stable >>

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

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

K>>>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг.
K>>>А вот Саттера и Мейерса очень рекомендую.
K>>>Именно как популизацию грамотного стиля и методик программирования на C++.

Ш>>Все трое -- ламеры.
S>А вот это мощно,

Да ладно, это естественно, гипербола.

Хотя, если серьёзно, тот же Мейерс частенько лажает.

S>я помню в своё время считал Вейерштрасса, Абеля, Коши просто м*даками

Ну это зря.

S>p.s. а ведь великие люди были.... чо то я бред понёс...

... << RSDN@Home 1.1.0 stable >>

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

Ш>Ты вот лучше объясни, почему я потроха STL знаю лучше, чем многие её адепты?

Подозреваю, потому, что ты — клевый программер

И, как минимум, изучал аспекты использования STL в своих задачах, причем не абстрактно, а с профайлером и исходниками в руках.

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

Ш>Да брось ты. Неужели осовение любого библа, хоть STL, хоть MFC, требует десятилетних усилий?

По-моему, слово "десятилетний" впервые всплывает в этом твоем сообщении.
По крайней мере, я ничего похожего не говорил.

Ш>А если так, то может это библо плохое?

C какой точки зрения? Вот упомянутая MFC — плохая библиотека?
Во многих технических аспектах — да.
В маркетинговых — нет. Потому что море отлично работающего кода под Win32 написано с использованием MFC.

И, кстати, MFC — это та же STL, но для Win32.
Потому что при всех ее недостатках она является реальным стандартом для программирования под Win32.
Причем быстрого программирования под Win32, потому что на MFC приходится писать в разы меньше кода по сравнению с WinAPI.
И, соответственно, ценность программиста, знающего MFC, несомненно выше ценности программиста, знающего только сишное WinAPI.
Я говорю в среднем, естественно. Не спорю, есть асы в WinAPI, которые заткнут за пояс десяток MFC программеров.
Но только на своих специфических задачах.
Для большинства же реальных задач уровня MFC хватает за глаза, и апишный хакер будет уже не просто оверкиллом, он будет вреден для проекта.

Тот же пример с вектором, который ты сейчас вынес на обсуждение в форуме С/С++: он в чем-то лучше std::vector, в чем-то — хуже, и главный вопрос, который остается — стоит ли игра свеч?
Т.е. стоит ли тот выигрыш, который ты получаешь по сравнению с конкретной реализацией STL (кстати, а действительно ли ты нашел и соптимизировал узкое место в программе, или это просто были мысли вслух?), с проблемами этого же решения, если оно работает не со строками, и с проблемами сопровождения (потому что программисту еще нужно будет въехать и в твой код, а STL он уже знает)?

P.S. И, в общем-то, мой тезис остается в силе.
Ибо даже если ты лично ты не используешь STL, ты можешь в каждом конкретном примере объяснить, почему, что как минимум подразумевает знание STL.
Следовательно, твоя стоимость как программиста, по сравнению с программистом, не знающим STL — выше.

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

Ш>Ну это зря.
А это почему?

понапридумывали, а потом мучайся

... << RSDN@Home 1.1.3 stable >>

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

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

Вопрос моды... Об этом так здорово сказал Пол Грэм, см. в частности его эссе о моде и ереси "What You Can't Say". Статья эта не о бусте конечно, а так, вообще. Если о чем-то современники слишком много говорят положительного, это может быть признаком вещи модной и не долговечной.

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

И еще много о чем шумят, не только о бусте. Так пусть каждый программер имеет свою голову на плечах и не идет на поводу таких вещей, как "придерживайся стандартов" и "все пишут на языке/платформе X".

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

Я доверяю только вещам, которые создавались отдельными людьми и при решении конкретных задач. С, С++, Unix относятся к таким. Вещи же, создаваемые группой авторитетов и исходя из общих соображений — всегда (всегда!) сюкс.

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

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

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

K>>>>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг.
K>>>>А вот Саттера и Мейерса очень рекомендую.
K>>>>Именно как популизацию грамотного стиля и методик программирования на C++.

Ш>>>Все трое -- ламеры.
S>>А вот это мощно,

Ш>Да ладно, это естественно, гипербола. :beer:

Ш>Хотя, если серьёзно, тот же Мейерс частенько лажает.

S>>я помню в своё время считал Вейерштрасса, Абеля, Коши просто м*даками :))) :beer:

Ш>Ну это зря.

Ну почему же? :) Тоже ведь живые люди были
Если я не ошибаюсь, именно Коши в сове время зарубил теорию групп Галуа

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

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

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

CT>Стандарты, кстати, сюкс, потому что их создают комитеты. А членами этих комитетов являются как правило теоретики, которые не создают реальных больших систем. Инструментарий для рабочего должен создавать сам рабочий, а не группа прорабов и путем голосования. Абсурд! (Тот же Грэм не любит джаву, в частности потому, что этот язык поддерживается комитетом.)

ну и дурак
нашел причину, достойную 13-летнего подростка

CT>Я доверяю только вещам, которые создавались отдельными людьми и при решении конкретных задач. С, С++, Unix относятся к таким. Вещи же, создаваемые группой авторитетов и исходя из общих соображений — всегда (всегда!) сюкс.

POSIX, разве, создавался не путем голосований?
Стандарт С++ и С — тоже не путем голосований?

Имхо, асоциальная позиция в стиле "все сакс, что принимается путем голосований или о чем много говорят" тоже имеет мало разумного.

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

CT>>Я доверяю только вещам, которые создавались отдельными людьми и при решении конкретных задач. С, С++, Unix относятся к таким. Вещи же, создаваемые группой авторитетов и исходя из общих соображений — всегда (всегда!) сюкс.

J>POSIX, разве, создавался не путем голосований?
J>Стандарт С++ и С — тоже не путем голосований?

Сначала все это создавали какие-то творческие люди, для решения каких-то конкретных сиюминутных задач. Комитеты и стандарты, как известно, возникают опосля. Кстати, это касается даже джавы. Но в случае джавы этому самому комитету удалось нанести максимальный ущерб первоначальной идее. Юниксу/Посиксу в этом смысле повезло чуть больше.

J>Имхо, асоциальная позиция в стиле "все сакс, что принимается путем голосований или о чем много говорят" тоже имеет мало разумного.

"Тоже"?

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

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

CT>>>Я доверяю только вещам, которые создавались отдельными людьми и при решении конкретных задач. С, С++, Unix относятся к таким. Вещи же, создаваемые группой авторитетов и исходя из общих соображений — всегда (всегда!) сюкс.

J>>POSIX, разве, создавался не путем голосований?
J>>Стандарт С++ и С — тоже не путем голосований?

CT>Сначала все это создавали какие-то творческие люди, для решения каких-то конкретных сиюминутных задач. Комитеты и стандарты, как известно, возникают опосля. Кстати, это касается даже джавы. Но в случае джавы этому самому комитету удалось нанести максимальный ущерб первоначальной идее. Юниксу/Посиксу в этом смысле повезло чуть больше.

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

J>>Имхо, асоциальная позиция в стиле "все сакс, что принимается путем голосований или о чем много говорят" тоже имеет мало разумного.

CT>"Тоже"? :)

"тоже" в сравнении с лозунгами конца 90-х "джава — это самая модная фишка и спасение человечества, поэтому С++ сакс, все идем писать на джаве".

Здравствуйте, Шахтер, Вы писали:
Ш>Хотя, если серьёзно, тот же Мейерс частенько лажает.
А в чем он лажает? Я недавно купил его книгу и начал читать. Мне она показалась интересной и поучительной. Пока не вижу нравоучений. Простой анализ конструкций языка и рекомендации по их использованию.

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

Ш>Да брось ты. Неужели осовение любого библа, хоть STL, хоть MFC, требует десятилетних усилий? А если так, то может это библо плохое?

Время освоения библиотеки прямо пропорционально кол-ву граблей в этой библиотеке

Здравствуйте, e-Xecutor, Вы писали:
Ш>>Да брось ты. Неужели осовение любого библа, хоть STL, хоть MFC, требует десятилетних усилий? А если так, то может это библо плохое?
EX>Время освоения библиотеки прямо пропорционально кол-ву граблей в этой библиотеке

Если бы зависимость была линейной.... это был бы рай на земле.

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

VVB>>>>ACE шагает по стране?

AC>>>Типа того. Дурной пример, он как известно заразительный

. На моей памяти, он лет пять как шагает.
ГВ>>А в ACE-то ты что плохого видишь? Вполне себе приличная либа.
AC>Хм, вроде как я не сильно очепятываюсь, слова, вроде, вполне читаемые получаются

А, ну тогда извини.

... << RSDN@Home 1.1.3 stable >>

Да, мода рулит!

Я тебе лучше расскажу, что бывает, когда ни STL, ни тем более BOOST’a нет. У нас есть большой проект. Побольше кода чем в BOOST+STL в несколько раз. Раз такой вещи как STL нет, то все изобретают аналоги каждый на свой лад. (Некоторые вообще этого STL, похоже, в глаза не видели, поэтому у них очень интересные штуки выходят

, но я отвлекся.) И вот у нас в проекте есть свой vector, свой map, свой smart_ptr и т.д. Если всё есть, в чем проблема? Проблем много. У каждого из этих классов свой незнакомый интерфейс, который еще надо изучить. А документации естесственно нет. Как что работает понятно только если облазишь не один десяток килобайт кода. Простейших вещей просто нет, или они не дописаны благодаря тому, что каждый писал под себя и те вещи, которые ему были не нужны он просто не счел нужным добавлять. Такие приколы как vector расширяется только на один элемент при добавлении в конец, я обнаружил не сразу. Это и другие “приколы” стоили мне многих часов отладки. Доморощенный map требует 20-30 строк кода + дополнительный класс, где используя STL-ный обходишься одной строкой. Продуктивность бешеная! Каждый раз, когда мне нужно использовать какой либо из таких классов, мне необходимо лезть и изучать заново его интерфейс, потому что запомнить такое разнообразие извращенских интерфейсов я просто не в состоянии. List как таковой отсутствует, потому как “а зачем тащить мегобайты кода”, когда можно написать каждый раз свой класс с двумя указателями. К сожалению это значит, что мне прийдется опять изобретать велосипед, когда мне понадобиться список. В место того, чтобы писать код, который нормально работает с первого раза, мне приходится отлаживать или дополнять доморощенную библиотеку. Я уже добавил туда кучу вещей, но я больше чем уверен, что другие их использовать не будут, потому что они как и ты предпочтут написать свои классы в несколько строк.

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

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

AC>>Если человек не спользует shared_ptr, а пишет свой класс в несколько строк, и не тянет за собой дцать метров сырков он ламер

AC>>Если он не использует мега-bind и function, а стыдно сказать, пишет свой кусочек кода в несколько строк он недостоен быть C++ программером

Да, мода рулит!

A>Я тебе лучше расскажу, что бывает, когда ни STL, ни тем более BOOST’a нет. У нас есть большой проект. Побольше кода чем в BOOST+STL в несколько раз. .... И вот у нас в проекте есть свой vector, свой map, свой smart_ptr и т.д. Если всё есть, в чем проблема?
Совершенно нормальная ситуция для проекта в области встраиваемых ситем при сильно ограниченном компилере, например.

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

A>Проблем много. У каждого из этих классов свой незнакомый интерфейс, который еще надо изучить. А документации естесственно нет. Как что работает понятно только если облазишь не один десяток килобайт кода. Простейших вещей просто нет, или они не дописаны благодаря тому, что каждый писал под себя и те вещи, которые ему были не нужны он просто не счел нужным добавлять.
Хм. Менеджера (или Лида) менять не пробовали? Причем здесь программирование или профессионализм девелоперов?
Я не говорил, что все должно быть в разнобой и писаться каждый раз новое под каждого человека и каждый проект. Я говорил о том, что STL и тем более BOOST — это не критерий, это только либы и причем не такие уж и удобные/надёжные/стандартные как того хотят показать. Причем местами совершенно не нужные, но по некоторым суеверным представлениям они должны быть (использоваться) везде.

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

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

AC>Я не говорил, что все должно быть в разнобой и писаться каждый раз новое под каждого человека и каждый проект. Я говорил о том, что STL и тем более BOOST — это не критерий, это только либы и причем не такие уж и удобные/надёжные/стандартные как того хотят показать. Причем местами совершенно не нужные, но по некоторым суеверным представлениям они должны быть (использоваться) везде.

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

НО: этот самый один человек должен учитывать, что над STL уже успело поработать огромное количество людей, и что он оптимизирован до невозможности. Реализуй свой вектор под свои конкретные нужды, но не забудь сравнить его производительность с STL. Возможно ты с удивлением обнаружишь, что какая-нибудь хорошая реализация стандартного вектора, как напр. GNU-сная — лучше твоей. Так тоже бывает.

К сожалению не могу сказать того же о бусте. Буст — это скорее "теория всего", которая обречена на забвение. Замахиваешься на всё — получишь ничего. Надо бы поскромнее быть

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

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

	От:	Alexey Chen
	Дата:	04.10.04 12:44
	Оценка:	45 (7) +1 -1

От:	VladD2	www.nemerle.org
Дата:	04.10.04 13:03
Оценка:	52 (9) +3 -1

	От:	Кодт
	Дата:	04.10.04 13:14
	Оценка:	+1

	От:	StanislavK
	Дата:	04.10.04 13:28
	Оценка:	3 (1) +3 -2

	От:	Сантехник
	Дата:	04.10.04 13:47
	Оценка:	+2

	От:	mapa3m
	Дата:	04.10.04 14:04
	Оценка:	20 (5) +3 -1

От:	jazzer	Skype: enerjazzer
Дата:	04.10.04 15:33
Оценка:	21 (6)

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	04.10.04 15:38
Оценка:	124 (14)

От:	Mr. None	http://mrnone.blogspot.com
Дата:	05.10.04 03:59
Оценка:	5 (2) +2

От:	Курилка	http://kirya.narod.ru/
Дата:	05.10.04 06:29
Оценка:

	От:	Kluev
	Дата:	05.10.04 09:30
	Оценка:	1 (1) +1 -2

От:	Sinclair	https://github.com/evilguest/
Дата:	05.10.04 09:34
Оценка:

	От:	mefrill
	Дата:	05.10.04 10:44
	Оценка:	5 (2) +1

	От:	Шахтер
	Дата:	05.10.04 20:32
	Оценка:	1 (1)

	От:	Юнусов Булат
	Дата:	06.10.04 17:46
	Оценка:

	От:	lightSource
	Дата:	06.10.04 19:50
	Оценка:	8 (4)

	От:	Дед Пихто
	Дата:	11.10.04 11:39
	Оценка:

	От:	alexeiz
	Дата:	13.10.04 22:11
	Оценка:	1 (1) +1