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

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

Моё имхо — кумулятивный эффект здесь — это
* количество уже написанного кода
* количество людей, знающих вот такой язык и умеющих на нём писать (причём не просто рожать 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 — это же следующий стандарт!'.
А я вот нечасто использую. Но дискомфорта от вероятного введения его в стандарт не испытываю. Равно как и от воплей. Пусть шумят те, кому нравится.

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

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

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, 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

Автор:
Дата: 04.10.04

.
В программировании слишком сильный уровень абстракций -- вреден. Почитай Джоела про "Закон дырявых абстракций".

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++.

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

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

Ясно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К>Моё имхо — кумулятивный эффект здесь — это
К>* количество уже написанного кода
К>* количество людей, знающих вот такой язык и умеющих на нём писать (причём не просто рожать 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>Не согласен? Ну, и бог с тобой.
Ну что ж!? Хорошее продолжение хорошей беседы! Буду в ваших краях — заскочу всенепременно.

Здравствуйте, 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 "+". (c) FIDO.

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

ГВ>Тут на самом деле не в 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++. А не вой относительно "ОО — рулез форева" или "темплейты — рулез там же".

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

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

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