Один из лучших компиляторов C++ для Linux прекращает существование

2anonymous (*) (2002-04-29 22:24:33.496):
> 1. "В С++ НЕ удалось реализовать концепцию защиты данных" ее не пытались реализовать,
> реализована защита от ошибки, а не от взлома.
Ваше цитирование моих слов вырвано из контекста! Я продолжал:
" все инкапсуляции со скрытиями, сильно мешая, элементарно (иногда случайно) обходятся."

> 2. " А ЦеППшные деструкторы - костыль, в половине случаев срабатывающий не так, как
> задумывалось." глупость, ну приведите пример когда "конструктор не так работает"...
> это как free не так работает... либо вы понимаете, как оно работает и пользуетесь
> инструментом либо не хотите понимать, но тогда не пользуетесь и не наезжаете
> необоснованно, логично?
Честно говоря, я уже задолбался отвечать на это. Тут вообще есть оппоненты, следящие
за моей логикой, или на всех вас слова "ЦеПП - нехорошо!" действует, как красная
тряпка на быка? :)

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

> если в документации написано, что не изменяет, а на самом деле изменяет, то это баг,
Согласен, это - баг. В документации.
> так-же как и если-бы это было с указателями, но с указателями вы бы не возмущались?
> непоследовательно :Р
Если бы ЭТО было с указателем, то я бы это увидел, что значение argc может изменяться,
и сразу понял бы про баг в документации! А тут - мне просто в голову не пршло, что чел,
писАвший документацию, чуть накололся - это своийство и называется читаемостью программ!

2Die-Hard:

" Речь шла о конроле за памятью. Я просто утверждал, что автоматически вызываемых деструкторов не достаточно для управления памятью в С++."

неправда ваша, не вывернетесь, вы утверждали дословно следующее: " А ЦеППшные деструкторы - костыль, в половине случаев срабатывающий не так, как задумывалось."

а по поводу printf... ну очевидно, что следующим ходом я сделаю так:

char *fmt;

printf(fmt,"засада");

накрылась "видность" медным тазом, но в прочем это флейм :)

2anonymous (*) (2002-04-30 00:01:03.123):
> " Речь шла о конроле за памятью. Я просто утверждал, что автоматически вызываемых деструкторов
> не достаточно для управления памятью в С++."
> неправда ваша, не вывернетесь, вы утверждали дословно следующее: " А ЦеППшные деструкторы -
> костыль, в половине случаев срабатывающий не так, как задумывалось."
Извиняюсь, Я за СВОИ слова ВСЕГДА отвечаю. Извиняюсь за самоцитату,

Die-Hard (*) (2002-04-29 21:58:27.5):
> Если уж так не нравится ручное управление памятью, надо мусор собирать.
> А ЦеППшные деструкторы - костыль, в половине случаев срабатывающий не так, как
> задумывалось.
Че, непонятно?

эх, Die-Hard, это похоже на вас слова С++ действуют как красная тряпка :(

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

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

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

по поводу ссылок... ну не увидели, ну запомнилось, нашли баг.

>> ты бы хоть Брукса почитал, что он про 200 индусов vs. 10 человек пишет...

неужели мои слова как-то противоречат Бруксу? я читал Брукса и за "индусскими" проектами на практике не первый год наблюдаю. И на качестве в своем комментарии я вроде бы тоже сакцентировал внимание. Команд, которые пишут OS/360 и иже с ними - единицы, а стартапов-дот-комов тысячи. Тут каждую умную мысль не считают, тут главное с какой скоростью проект "набирает массу" (читай: есть, что показать инвесторам). Вот это и определяет популярность инструмента/языка в _реальной_ жизни.

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

2anonymous (*) (2002-04-30 00:01:03.123):
Ух, со злости отправил предыдущий мессаг, не ответив до конца! :)

> а по поводу printf... ну очевидно, что следующим ходом я сделаю так:
> char *fmt;
> printf(fmt,"засада");
> накрылась "видность" медным тазом,
1. А оно надо?
2. Если надо, то, очевидно, я посмотрю, что такое *fmt, если будет ошибка выползать.
В отличие от init_gui(i,c); где напрашивается вывод о передаче
первого аргумента по значению, а не по ссылке.

> но в прочем это флейм :)
Точно!

" Че, непонятно?"

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

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

2anonymous (*) (2002-04-30 00:15:33.798):
> эх, Die-Hard, это похоже на вас слова С++ действуют как красная тряпка :(
Точно! :)
Безумно жаль загубленную молодость :)))

Далее, извиняюсь, в Вашей мессаге комментировать как-то нечего. Похоже,
Вы меня не внимательно читали ;)

2All (особенно AC):
Безумно извиняюсь - покидаю вас до 15 мая. Боюсь, не смогу на ЛОР зайти, чтобы вам ответить -
если только на Крите нет интернет-кафе.

" В отличие от init_gui(i,c); где напрашивается вывод о передаче первого аргумента по значению, а не по ссылке."

C-шные привычки :) хотя этот случай да, через задницу написал кто-то :) но это же не повод чтобы говорить, что ссылки вообще вредная вещь :)

спать-то будем или нет? у меня пол четвертого уже :)

как это нечего комментировать? можно прокомментировать про защиту в рамках совместимости с С, есть мнение как сделать лучшую, чем сейчас в С++ ? :)

остальное завтра

2 Die-Hard: >Деструктор не будет вызван, если вы забыли сделать delete объекту из кучи;)
До чего же вы упрямы. Вы не просили вызвать деструктор, он и не будет вызван. Аргументация -- "память не будет освобождена, если вы забыли сделать free." Или "память не будет освобождена, если вы забыли сказать free после cleanup". В C я _обязан_ перед очисткой памяти не забыть вызвать очистку объекта. Если позабуду -- поимею проблем. В С++ хоть с этим заморачиваться не надо.
>только автоматические объекты вы фактически оставляете за бортом весь полиморфизм
нет.
>Я смотрю на запись A(i,j) в файле xxx.cpp НЕ проходя предварительно по 1001 хидеру
Если вы ищете только строку A(i,j), и смотрите на нее через окно десять на десять пикселей, тогда -- да. А если вы видите конструкцию
for(unsigned int i=0;i< A.ncols();++i) {
A(i,1)=0;
} или
int pivot_row = bla-bla-bla;
double scale = 1/A(pivot_row,j);
то смысл такой записи очевиден. _Как_ здесь можно перепутать с конструктором, если специально не ставить себе такой задачи?
>Я много лет писал на С++ и считал его чуть ли не венцом творения, пока не понял, что он не справляется с декларированными обязанностями
В общем, ясно. Вы писали на C++ исходя из каких-то собственных о нем представлений, а когда обнаруживали, что эти представления расходятся с реальностью, винили в этом язык. Все равно что проклинать небо за то, что оно не хрустальное, как вы думали в детстве.
>Теперь я за всем слежу сам, и оказалось, что это - значительно надежнее и - легче.
Ну, если вам за всем проще следить самому, пишите уж в кодах, что мелочиться. Там вообще контроль абсолютный.
>"Нестрого типизированный" язык
Уж лучше нестрого типизированный язык, чем убого типизированный, в каком типы данных за каким-то боком есть, а вот толку от них реально чуть.
>они все реализуются через макросы ПРОЗРАЧНО ДЛЯ ПОЛЬЗОВАТЕЛЯ!!!
Шаблоны реализуются через макросы в самом тривиальном случае. Макросы не дают контроля типов. Макросы не дают специализаций. Макросы плохо контролируются. Макросы трудно отлаживать. Макросы делают исходный код нечитаемым. Макросы нельзя разделять в пространства имен. Конфликты имен макросов -- вообще смертельная вещь. Макросы кое-как подходят только для реализации самых тривиальных типов контейнеров. Макросы вообще не были придуманы для generic programming, а для других целей -- притаскивать их за уши к задаче, для которой они не приспособлены -- бред.
>То-то и оно, что "можно", но в языке для этого явных средств нет.
Есть. Шаблоны и перегрузка операторов.
>Точно так же! Хочется - пиши, или используй готовые либы.
Сделайте мне на C читаемую, отлаживаемую реализацию хотя бы смарт-пойнтеров с подсчетом ссылок, которая была бы прозрачна для клиента.

> Ты понимаешь, что в C++ практически нереализуемо понятие "текущего окружения"? Как в такой ситуации можно closure передавать?

Запросто, имхо.

Пишешь класс с одним публичным виртуальным методом run. Потом на каждый чих своего потомка, запоминающего нужные тебе переменные и исполняющего нужные тебе действия. Моя попа... впрочем, глянул вот в зеркало -- и правда, на две половинки :( А твоя цела?

Смоляное Чучелко

> я не слишком далеко в изучении OCaml продвинулся, застряв еще на функциональной части.

Ну, в изучении-то я тоже не слишком, хотя прочёл таки всё

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

А чего тут понимать? Запятые в перечислениях параметров _никогда_ не ставятся. a, b -- это порождение пары. Эсли у ты нужна именнно пара значений (функа описана как ('a*'b->'c)) -- пишешь f (a, b). Эсли просто два параметра ('a->'b->'c) -- то безо всякой запятой f a b

Вот точки с запятой -- это проблем...

> не так давно писал числодробительную программу на С++, так там мне безумно надоело писать все эти классы

А зачем в числодробилке классы? ++ (по сравнению с Цэ) весьма хорош и без оных, имхо...

> мне кажется у С++ очень красивый синтаксис. В конце концов template<class T>

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

> синтаксис Лиспа я считаю удобным > не сталкиваясь при этом с проблемой, как задать их приоритеты/ассоциативность

Великолепно! Язык, в котором ассоциативность и приоритет операций отсутствуют как класс, не имеет проблем с оными понятиями! Ну кто бы мог подумать...

Смоляное Чучелко

> Smalltalk - если хочешь посмотреть как может выглядеть нормальный OO-язык.

Нормальный ОО-язык? Без множественного наследования? Право же, бред.

Кстати, единственно нормальный в современных условиях -- Oject REXX, имеемый, кстати, и под linux. Единственный язык, где объектность совмещена с параллелизмом.

Смоляное Чучелко

> Не, не могу не встрять: инъекция -- это не есть взаимно-однозначное соответствие. Взаимно-однозначное соответствие есть БИЕКЦИЯ. Нет, и я встряну: взаимно-однозначное соответствие называется сюръекция. Говорят, что функция сюръективна.

>Сторонникам C/C++. Если какой-либо способ найти библиотеку/шаблон для выполнения конкретных функций ( www.google.com не предлагать ;-) ). Я большей частью администрю, и код пишу для склеивание различных систем. Перл в этом отношении прелесть. Регулярные выражения, хеш-массивы , списки - все это встроено в язык и без заморочей и риска легко Вы не очень удивитесь, если я скажу, что списки-хэши-деревья давным-давно есть в стандарте на библиотеку C++? (Ну, хэши - почти :) в стандарте, но по факту они есть всегда, и во всяком случае в стандарте есть map). Регулярные выражения - на выбор: POSIX regex (для юниксоводов), pcre, boost regexp.

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

Я не пойму, чего тебе в организации ROOT не хватает? Шаблонов?

> на лицо какое-то бесконечное дублирование кода.

?? Где? Если и есть дублирование, то исключительно ради быстродействия

> СЕРЕБРЯННОЙ ПУЛИ НЕТ.

Млин, скажите кто-нить болвану vsl, чтобы он выучил правило 4-го класса "стеклянный/оловянный/деревянный". Только начнешь серьезно читать его излияния, как натыкаешься на перл типа "серебряННый", и все желание воспринимать этого человека серьезно пропадает.

2 Die-Hard (*) (2002-04-29 01:29:08.431)

Привет. Я, конечно, могу не так понять, но дословно вы писали "А в ЦЕРНЕ и ДЕЗИ..." :) (Я иногда храню архивы...) :)

Виндузятник

2bugfixer:

Не хочется быть занудой ;), но for_each -- это т.н. non-modifying sequence operation (в отличии от transform, которая mutating sequence operation), поэтому изменять с помощью неё элементы контейнера не есть хорошо. Для double это как правило будет работать, но для остальных случаев -- не факт.

2all:

К сожалению всё больше и больше доказательств того, что C++ ругают преимущественно те, кто либо никогда не участвовал в разработке более-менее серьёзных проектов (а для небольших проектов все средства хороши), либо просто не знает и не работает с C++ (типа "ВЕЛИКИЙ Я на этом не пишу -- значит це гумно").
С++ -- идеальный язык для написания _больших_ и _критичных_к_скорости_ проектов. Пример с гуглом был очень в тему. При минимальном приложении рук можно обеспечить вполне приемлимую переносимость кода. Мало того, он позволяет при необходимости встраивать код практически на любом языке и сам может встраиваться практически в любой язык.
В реальных проектах, пишущихся на C++, используются большинство из его возможностей: исключения, чтобы не нагромождать кучу непонятных и несовместимых кодов ошибок; шаблоны, чтобы не писать по 100 раз один и тот же код для разных типов (и не говорите, что макросы тут замена -- где в макросах хотя контроль типов например); STL юзается на всю катушку, в результате чего многие сишные глыбы кода сворачиваются в одну строку кода на C++ и т.п. Причём используются не потому, что они есть и было бы круто из использовать, а потому, что с ними действительно удобнее писАть код.
С другой стороны, C++ позволяет писАть код в любом стиле (и дядя Страус об этом прямо пишет), в результате чего при отсутствии культуры программирования код превращается в помойку. Но эта проблема решается введением единого стиля кодирования и регулярной выверкой кода.
И прочитайте вы наконец хоть какие-нить книжки прежде, чем ругать "недостатки" C++.

Кстати, господа программеры, чтобы не быть голословными, напишите plz

1). Кол-во проектов, в которых вы участвовали. Желательно со ссылками на web-ресурсы.
2). Объём работ по этим проектам (хоть в человеко/часах, чоть в строках кода -- неважно) и какая часть от проекта была выполнена лично Вами.
3). Языки программирования, которые при этом использовались, и кто принимал решение о выборе именно этого языка. Желательно объяснить этот выбор.
4). Результаты по этим проектам (завершён успешно, завершён неуспешно, в процессе, не завершён и т.п.).

2anonymous (*) (2002-04-30 03:52:57.714):

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

anonymous (*) (2002-04-30 10:25:12.409):

Конечно в чем-то ты прав. К большим проектам я бы добавил - однородных по языку (что бы не заниматься линковкой фортрановских модулей и java программ :-) ). Но тут просто засел было тупой Die-Hard, на которого С++ как красная тряпка на быка. У меня возникло то же ощущение, однако как справедливо говорилось значительно выше во-первых можно выбрать другой язык, а во-вторых С++ не лишен недостатков, даже на собственных задачах (ты наверное и очертил их круг, хотя тут было много попыток).

> В случае выброса исключения из конструктора не выполняется деструктор. А зачем выполнять деструктор, если объект ещё не сконструирован, дурень?

2anonymous (*) (2002-04-30 09:44:21.85):

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

for( int i = 0; i < 5; i++) { DrawRectangle(i); }

Это отнюдь не увеличение счетчика i, от которого избавляешься дублированием.

2anonymous (*) (2002-04-30 10:48:19.218):

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

Был задан четкий вопрос - когда не вызывается деструктор. Выдан ответ. И тут лезет человек, не прочитавший со своими глупостями и знанием языка С++ и логики.

to antichrist
1) насчёт микроядерности Open VMS:
смысл моей фразы: мне сказали люди, заслуживающие доверия, что опен ВМС имеет элементы микроядерности, НТ же явно микроядерка. Своего ИМХО я НЕ выссказывал - я некомпетентен в вопросах НТ-ВМС.... (и много чего ещё)... Далее я обещал уточниться у источника насчёт "почему и в чём заключается микроядерность ОпенВМС и НТ"... Если ты кроме собранных в талмуд собственных выссказываний и речей своих апологетов ничего не читаешь - то это твоя проблема... Если память подводит - записывай :)... Или для тебя я "дестабилизирующий фактор" по личным причинам? :D

2) Список
По уровню отхода от железок:
HDL == VHDL, Verilog
Низкоуровневые или близкие к железке == asm, C (кто-то даже мп мк пишет на с)
Далее == C, C++, objective C....
А далее-далее не интересно.. :(

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

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

ИМХО (которое, как и любое другое, тебя совершенно не интересует) в частности OCaml - интересная штука, но из-за (а) малого количества спецов / инфы (б) малого количества действующих/законченных открытых проектов (в) ... Несмотря на свою относительную лёгкость в освоении - штука весьма, мягко сказать, специфичная...


to anonymous (*) (2002-04-28 23:24:41.986)
Я не госслужащий, :) и почти никакого отношения к "государству" не имею... :)

Извиняюсь за оффтопик... :) Флейм так флейм...

2anonymous (*) (2002-04-30 03:52:57.714):

За OCaml - спасибо за разъяснения. Насчет типов и шаблонов - я плохо понял твое высказывание. Мне казалось, что достаточно написать шаблон для того, для чего нужно. Если ты хочень например в контейнере только окна хранить и показывать их одновременно, то вперед, пиши, как будто есть у объектов функция Show. Но если я не правильно понял, то поправь.

2soneofus (*) (2002-04-30 10:56:33.541):

А почему уголовное наказание тогда?

>Взаимно-однозначное соответствие есть БИЕКЦИЯ. 
>Нет, и я встряну: взаимно-однозначное соответствие 
>называется сюръекция. 
>Говорят, что функция сюръективна

Сюрьективное и инъективное отображение 
есть биекция

:-)
Bear

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

2AC

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

>Вопросы со стороны -- вот вы так красиво рассуждаете, 
>а не могли бы _конкретно_ объяснить, 
>_как_ именно_, к примеру, шаблоны влияют на производительность. >Далее, _как
.....................

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

Если спросите Почему или Зачем
Отвечу: "Я думаю, что так лучше и быстрее и надежней".
Я даже уверен, что my way is the best :-))

Все остальное - как сложится (так мне это не очень важно)

Bear












 

2asoneofus (*) (2002-04-30 11:34:14.335):

Прости, но тогда вам с А/Х в одной камере сидеть, и должен сказать довольно долго!

2anonymous (*) (2002-04-30 11:54:31.006)(AKA Bear):

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

Шаблоны, это ведь опять несколько другой стиль мышления ( по сравнению с ООП и процедурным), сходный, как мне кажется с функциональным языком. Только так я могу объяснить то, что никакой ломки сейчас, при изучении ОСaml не замечаю. Опять таки - жаль, ведь это развивает.

to anonymous (*) (2002-04-30 04:02:39.993) aka Смоляное Чучелко 

>> синтаксис Лиспа я считаю удобным 
>> не сталкиваясь при этом с проблемой, как задать их 
>> приоритеты/ассоциативность 
> Великолепно! Язык, в котором ассоциативность и приоритет операций 
> отсутствуют как класс, не имеет проблем с оными понятиями! Ну кто бы 
> мог подумать... 

Вот как раз речь о том и идет, как *удобно это отсутствие*.
Для меня лично это лишь очередное подтверждение, что прав был Уильям Оккам:

 Pluralitas non est ponenda sine neccesitate.


Или, в более современном варианте:

"Есть человек --- есть проблемы. 
 Нет человека --- нет проблем." 
              (с) И. Джугашвили

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

--
SVK

Нафиг... :) Ему камеру - мне лесоповал :)...
Да и проходящих по одному делу в одни ИТУ не шлют... :) Это радует...
А вообще - бодяга длинная: заявления писать, пока разбираться будут.... Судягой надо родиться - стать им тяжело :(...

Помяни его - он и появится :) Погодь, отработает на благо фундаментальных исследований - придёт оттянуться... :)

И где это так херово алгебре-то учат? Сюръекция есть отображение "на", когда для любого элемента того множества, куда отображается, найдётся прообраз.

А вообще-то в сад. Учебники читать.

ДВ

2asoneofus (*) (2002-04-30 12:20:03.028):

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

Я пока только до середины дочитал... Тяжело идёт :) Но уже хочу высказаться, сразу по нескольким поводам. Итак:

1. Несколько первых примеров кода были вовсе и не С++. Ну где вы видели в *правильном* С++ использование malloc/free? Правильно, у С-шников заядлых :)

Перед пунктом два - немного о себе (там был вопрос о людях, которым платят деньги за программирование). Я работаю программистом, должность называется Principle Software Engineer. Это - последняя ступенька перед Architector (дальше уже только Senior Architector - и всё). Так что деньги мне платят неплохие (хотя их всегда нехватает). Фирма наша (Informatica) занимается тем, что пишет большой продукт для больших компаний. Просто для примера: почти все из 100 крупнейших компаний мира - наши клиенты.

Продукт наш занимается обработкой данных - читает из FlatFile/VSAM/RDBMS/XML/SAP/Siebel/PeopleSoft/MQ/FTP/Terradata/etc, обрабатывает (полный набор, включая фильтры, expressions, aggregations, stored procedures' calls и т.д. и т.п.) и пишет это всё в вышеуказанный список. Крутится сервер под NT/Solaris/HP/AIX/DEC-True64. У одной из компаний наш сервер крутится на 96-процовом HP, а данные ему подгоняет 64-процовый HP. Нехилые такие машины, скажу я вам.

Так вот (ох и наговорил...), писано всё это на С++. Особо критические участки на ASM не переписаны по одной простой причине - их невозможно поддерживать на стольких платформах!!!!

2. Про MSVC. Я работаю в сервер-группе, и у нас почти все - юниксоиды. Многие сидят под gvim 6 + C-scope (для tags), и творят на нём просто чудеса. Но, когда дело доходит до отладки, эти люди всё же запускают MSVC... Как не крути - а приятно переставлять instruction pointer вперёд-назад, и иметь edit-and-continue :) (gdb и близко рядом не стоял)

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

4. Для любителей отстоять чистоту С советую взглянуть на чисто-С-шный исходник того же vim ;) Такое болото не часто встретишь

5. Template и virtual functions полностью взаимозаменяемы? Ну... Иногда - возможно. Но чтобы вот так, с плеча, я бы не стал. И у тех и у других есть своё применение. И оно очень даже отличается (и скорость здесь не на первом месте). Попробуй реализуй передачу объектов по сети, и быстренько предпочтёшь virtual functions. А если твоя програма должна обрабатывать данные либо в ASCII, либо в UNICODE, то тут уж template'ом пахнет

6. А вот больших проектов на Java, ASM, C(!) я что-то на практике не встречал. Средних размеров - бывало. Но реалии жизни таковы, что сегодня средний размер проекта на VisualBasic больше, чем на С. Так что - назад, к Васику?

7. ООП... И кто же это тут говорил что *С++ и ООП не имеют ничего общего*? Интересное замечание... Особенно, учитывая, что С++ как раз и развился-то только под влиянием ООП (и ничего более!!!)

8. Называть Страуструпа идиотом, это, простите, уже много. У кого-нибудь из присутствующих есть звание профессора в выч. технике? Или всемирное признание? Или своя ралигия, как тут кто-то назвал С++? Нету? Так нЕчего хаять попусту, только слюнями разбрызгиваться.

Ох, ну и наговорил, пальцы болят. Ах, да. По поводу Джойнера. Всё-таки интересно, как умные люди подтасовывают факты для получения *правильных* выводов :) 1. Автор утверждает, что ни С, ни С++ не являются, в академическом смысле, языками высокого уровня, на основании того, что эти языки *не хранят вспомогательную информацию* в тексте. Так что - Бейсик тоже язык низкого уровня? :) И Visual FoxPro - это хороший пример такого языка? 2. Тот же автор утверждает далее, что *плохих программистов продвигают в менеджеры, где они будут приносить меньше вреда*. Мой жизненный опыт совершенно не подтверждает сей факт (может, мне повезло работать в хорошей фирме???) 3. Ну, про синтаксис С++ можно долго спорить, но обзывать его недостойным никак нельзя. Ведь никто же не говорит этого про Паскаль, хотя бесконечные Begin/End уже всех достали до печёнок 4. Про поинтеры уже сказано много, и каждый раз их хают за NULL, утечку памяти и подобное. И ещё больше их нелюбят за многоуровневые indirections. А вы когда-нибудь пробовали по-пользовать указатели на функции с умом, или вместо многоуровневых указателей использовать структуры? Мой последний проект был ускорить работу большой части нашего сервера. Использование указателей на функции позволило сэкономить 1% CPU time. Да, такое задание должно быть выполнено аккуратно, и со знанием дела. Но ведь для этого и есть разные уровни инженеров? А насчёт указателей - у нас есть код, в котором используется 4-кратная вложенность. А ничего не поделаешь - так надо. Выручает простая абстракция, и без потери производительности, между прочим 5. Операторы. Перегрузка оных может быть твоей погибелью, а может быть и спасением. Всё зависит только от дизайна - ножом, тоже, можно и масло резать, а можно и глотку 6. Ладно, не буду больше о этой книге. Хватит уже пунктов. Добавлю только, что автор так и не потрудился дать решение всем тем проблемам с языком (языками вообще и С++ в частности), что низводит его труд до уровня каркающей вороны

2YePhIcK (*) (2002-04-30 12:27:25.848):

Насчет virtual functions и templates - естественно, подразумевалась принципиальная заменимость. Использовать одно на месте другого - бред.

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

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

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

Лес валить - не магнитоспектроскопы таскать :) Там достаточно веса амплифазометра... :) (смешное такое слово - но штука стоящая :) и не очень тяжёлая)
Ладныть... крибля-крабля-всё..блин-прекращаем...блин - тут люди мысли интересные выссказывают :) А мы тут о лесоповале :), право неудобняк...

2 Bear: >Если спросите Почему или Зачем Отвечу: "Я думаю, что так лучше и быстрее и надежней". Я даже уверен, что my way is the best
То бишь, _объяснить_, почему вы так думаете, вы не можете. Стало быть, это -- предубеждения и религия. "Шаблоны снижают производительность, потому что _я_ так _думаю_". Все ясно, базара нет.

>Ну, про синтаксис С++ можно долго спорить, но обзывать его недостойным никак нельзя.
В синтаксисе C++ достаточно труднопонимаемых/никак-не-очевидных вещей. Достойным-красивым-удобным его никак не назовешь.
>А вы когда-нибудь пробовали по-пользовать указатели на функции с умом
Пробовали. Указатели на функции -- зло. Это понятно любому, кто имеет хоть какие-то представления об оптимизации.
>у нас есть код, в котором используется 4-кратная вложенность.
Четырехкратная вложенность??? Указатель-на-указатель-на-указатель-на-указатель-на указатель? И все четыре уровня используются одновременно??? Ну это же, извиняюсь, довольно бредово. Хотя бы, вы только представьте, как это все тормозит.

2AC 

>То бишь, _объяснить_, почему вы так думаете, вы не можете. 

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




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

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

Еше раз: мне так удобнее и во всех известных
мне случаях мой код работает _не_ медленнее 
любого другого.


>Стало быть, это -- предубеждения и религия. 
>"Шаблоны снижают производительность, 
>потому что _я_ так _думаю_". Все ясно, базара нет.

Это мне показалось или Вы и в самом деле 
думаете, что имеете дело со старым маразматиком
которого Вы можете легко задавить интеллектом?

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

Причем я не зацикливаюсь. Я просто говорю свое 
мнение, которое возникло из опыта. 
Не хотите слушать - не настаиваю.

ОбЪяснить можно все. 
И я умею объяснять не хуже любого (и лучше слишком многих).

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

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

Все! Успехов! 

Bear

2АС 

>Четырехкратная вложенность??? 
>Указатель-на-указатель-на-указатель-на-указатель-на указатель? 
>И все четыре уровня используются одновременно??? 
>Ну это же, извиняюсь, довольно бредово. 
>Хотя бы, вы только представьте, как это все тормозит. 

Слушай, парень, ты думаешь что ты самый умный?
Тебе это случаем не мама сказала?
Или став умнее мамы ты решил, что все глупее тебя?

Bear

2 Bear: >Меня поражает нахальство некоторых - нахаляву узнать то до чего еще долго самому доходить
Почему нахаляву?
>мне случаях мой код работает _не_ медленнее любого другого.
А меня поражает нахальство и самоуверенность некоторых таких типа "умудренных опытом старых зубров". Которые думают, что это они одни типа начали работать, когда их собеседники пешком под стол ходили.
>Но у Вас были преподаватели лучше чем у меня.
Вы неправильно выразились. Не преподаватели -- воспитатели.
>Слушай, парень, ты думаешь что ты самый умный? Тебе это случаем не мама сказала?
Нет, не мама. Воспитательница, конечно же. В нашем детском саду, естественно. Уж извини, старичок -- ухожу кушать кашку и на тихий час. Опыт наращивать. Он ведь только у вас есть.

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

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

Про большие проекты на Жабе - посмотри хотя бы на ненавистный Together Control Center. Аналогичный продукт на C++ - Rational Rose - всё же гораздо кривше, глючнее и функциональности поменьше имеет. "Средним" проектом я бы это не назвал.

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

Про C++ и ООП - ты это заврался сильно. В C++ множество сущностей, никак на ООП не ложащихся. Те же темплейты. Да и множественное наследоваение - фича крайне сомнительная.

Про альтернативу C++, предложенную Джойнером - ты просто плохо читал. Он как раз сравнивал C++ с Java и Eiffel. Ну да он фанат ООП, потому и список такой ограниченный. Мой список ты видел выше, на 1-й или 2-й странице.

В общем, моё мнение: язык, на котором не выразить функциональные комбинаторы - говно, а не язык. ;)

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

Твой список же, претендующий на отражение рыночной действительности, грешит позорными упущениями. Ты забыл Форт как наиболее массовое средство для низкоуровневых ембеднутых задач, ты записал C++ в средства рисования гуйни, забыв даже Tcl и такую попсу, как VB и Дельфи.

И вообще, не надо про массу. "Миллиарды мух не могут ошибаться - всё же, в говне что-то есть!".

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