Актуальность C++ !!!

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

Так себе шутка. Попроси каждого 2-го на ЛОРе, он такое интервью напишет. Еще можно написать про тупейшие механизмы шаблонов, принципы работы которых не понимает никто, про кривую иерархию классов без единого базового класса, про дурацкие указатели и ссылки и т.д.

Мое мнение - этот язык не умрет еще долго. Несмотря на то, что многие считают его ущербным

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

Сейчас, видимо, это происходит в порядке подготовки.

to ukez:

> Еще можно написать про тупейшие механизмы шаблонов, принципы работы которых не понимает никто

Ну это ты зря таг загнул. Шаблоны ох как сильно облегчели мне жизнь

to sdr:

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

to ukez:

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

to sdr:

На такой слоган даже отвечать не интересно. Использование стандартной библиотеки возможно до первого нестандартного случая. Как только тебе потребуется вникнуть в релизацию некоторой шаблонной библиотеки ( см. STL или boost ) начнутся проблемы

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

Речь идет не о generic programming вообще, а о ее ущербной реализации в
виде шаблонов в плюсах.

> Мое мнение - этот язык не умрет еще долго. Несмотря на то, что многие
> считают его ущербным

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

to int19h:

>VB тоже жил долго, да что там, до сих пор подыхает. И кодеров на нем

>писало немало. Однако от этого он не стал лучше как язык. Просто ни

>время жизни, ни популярность не являются критериями рациональности и

>эстетичности языка.

Согласен. Но тут вопрос не в эстетике и рациональности, вопрос в сложившихся традициях в области разработки ПО.

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

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

Это не делает их менее кривыми. Даже если с гигиеной R5RS сравнивать...

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

Тот же Лисп легко и непринуждённо заменит C++ абсолютно во всех задачах, где C++ применяется. Но почему-то быдло пишет на C++, а не на Лиспе. Наверное, потому, что оно - быдло...

Упс.... любую задачу моно сделать на любом языке, это аксимома. Вопрос чего это будет стоить? Что там насчет производительности у лиспа, а? Для справки - при ПРАВИЛЬНОМ использовании С++ по этому параметру не отстает от С, проверено опытом:-)

На перле ОСь????

Ну так Лисп при правильном использовании C++ часто обгоняет по производительности. Однако, производительность в большинстве случаев - далеко не первой важности фактор, гораздо важнее скорость разработки. Вот тут у Лиспа вообще конкурентов нет.

При ПРАВИЛЬНОМ использовании Lisp тоже не сильно отстает от С ;) -- во-всяком случае, не настолько, чтобы это имело значение для 90% задач, а разговоры о низкой производительности Lispа как правило ведутся людьми, его в глаза не видевшими (я, конечно, имею в виду Common Lisp).

Кроме того, что такое правильное использование С++? Если не использовать STL, RTTI, exceptions, virtual functions, то код на C++ вряд ли может быть медленее эквивалентного кода на С -- скорее наоборот, потому что более строгая типизация обычно способствует лучшей оптимизации

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

Про скорость разработки - согласен (хотя интпресно бы сравнить по этому параметру лисп с тем же пиотоном или напр руби или хаскелем...).

Токо все ж что называть правильным использованием лиспа? Для высокоц производительности той же нуно ручное управление памятью и еще ряд низкоуровневых операций, так ли уж удобно их делать на лиспе по сравнение с тем же С++?

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

Правильное использование - напр объекты не возвращать тупо:-) и не присваивать.... кстати моно (такие есть) написать либку для работы с маритцами и пр. лин алгебры, к-я будет раскручивать операции в общий цикл с производительностью сравнимой с С и иметь при этом оч.лаконичное и читаемое использование... но это непросто.

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

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

to Cantor:

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

Так и я об этом. Только вот оптимизирующий компилятор делает это гораздо эффективнее человека!

Угу. Однако, преодолеть теоретический предел для одного алгоритма можно, заменив его на другой, более производительный (e.g. пузырьковую сортировку заменить на слияние). Языки с высокой степенью абстракции и возможностью статического анализа позволяют частично автоматизировать (на уровне компилятора!) такую вот алгоритмическую оптимизацию.

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

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

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

Ну а если заместо ocaml-а взять что либо с компактифицирующим stop'n'copy проходом GC - то тебе и вовсе ничего не светит.

А что тут комментировать? Почитай про современные алгоритмы memory management-а. С такой оптимизацией в runtime ты никогда не сможешь сравниться с какой угодно ручной СТАТИЧЕСКОЙ оптимизацией - поскольку не можешь заранее предсказать все возможные виды нагрузок на MM твоего кода.

> А что тут комментировать?

для многих задач хорошо подходит то что в gcc называется obstack, или в библиотеке OpenCV называется CvMemStorage

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

Ну так это уже ни разу не ручная статическая оптимизация, а как раз аналог динамического memory management-а.

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

> Токо все ж что называть правильным использованием лиспа? Для высокоц > производительности той же нуно ручное управление памятью и еще ряд > низкоуровневых операций, так ли уж удобно их делать на лиспе по > сравнение с тем же С++?

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

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

Сразу скажу, что под ручным MM я понимаю ММ логика работы которого может быть реализована пользователем исходя из его задач, а не тупо забита "для наиболее общих случаев"

Из тех лозунгов которые тут были оглашены я так и не понял как компилятор оптимизирует процесс выделения памяти если более или менее полезный статический анализ программы невозможен и трудно предсказать насколько часто выполняется тот или иной участок кода ? И как стандартый динамический ММ угадает страегию выделения/освобождения памяти в моей программе ?

Зачем угадывать - он её измеряет динамически.

В общем, тебе - то же задание. Обгони вручную MM в OCaml-е. После того, как попробуешь, все вопросы сами отпадут.

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

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

> Из тех лозунгов которые тут были оглашены я так и не понял как
> компилятор оптимизирует процесс выделения памяти если более или менее
> полезный статический анализ программы невозможен и трудно предсказать
> насколько часто выполняется тот или иной участок кода ?

В этом треде уже несколько раз всплывало словосочетание "статический
анализ" в контексте слова "лисп". Почитай еще раз, а?

Какое отношение статический анализ имеет к lisp-у ?

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

Lisp не содержит более или менее вразумительных средств описания структур данных и недалеко ушел в этом плане от C++ или Pascal (более того форма eval может вообще загубить весь статический анализ на корню)

плюс импераитвные возможности Lisp-а тоже не способствуют статическому анализу

Это очень спорный момент. В CMUCL/SBCL type inference работает в общем не хуже чен в ML, хотя система типов в CL конечно другая. Но ML-подобные рекурсивные типы в Lispе реализуются без особых проблем -- есть такая библиотечка, например, TypeL.

Что касается eval -- то ни один нормальный человек его не использует.

Есть случаи, когда eval юзать можно и нужно - тот самый message passing, недавно тут обсуждавшийся.

Ну случаи-то конечно бывают -- но используя eval, о производительности можно забыть (в частности потому что если в системе нет честного интерпретатора как в cmucl/sbcl, то перед выполнением код будет компилироваться).

Как правило, при message passing выполняемых s-expressions объём интерпретируемого кода минимальный.

>Какое отношение статический анализ имеет к lisp-у ?

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

>Lisp не содержит более или менее вразумительных средств описания >структур данных и недалеко ушел в этом плане от C++ или Pascal >(более того форма eval может вообще загубить весь статический анализ >на корню)

Если в Лиспе объявлять все типы явно, то компилятор статически оптимизирует замечательно, можно посмотреть выведенные типы при каком либо вызове и т.п.

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

IMHO Лисп имеет довольно развитую систему типов, хотя в силу ориентированности языка на динамическую проверку типов, она не столь эффективна как система типов Хиндли-Милнера. Например в Лиспе списки гетерогенные и делать что-то вроде list<fixnum> смысла нет.

С++ далеко не хуже Lispa.
Наверное главный плюс это богатство готовых решений(библотек и т.д.).
С++ болие чёткий и сложный синтаксис ЧТО ЛУЧШЕ для нахождения ошибок.
Все минусы которые касаються шаблонов и т.д. хе... да просто их можно не использовать! Кто нам запрещает их не использовать?

Товарищь, ты не в теме. Наверное, ты ещё маленький. Учись.

ну чё могу сказать в ответ... а ничего так как оскорбления игнорю.
И C/С++ форева а всё остальное must die дальше думайте сами :)

С++ sucks forever ;-)