Плюсы C++

[vitus_wagner]

Тут сегодня в debian-russian кто-то высказался, что де у C++ есть плюсы и минусы. Минусов больше.
Не могу не согласиться. Я знаю целых два плюса C++. Оба - в названии.

Comments

[fr0ster.livejournal.com]

Однако боян.
Да и вообще, 80% минусов С++ происходят или от попыток писать "помодьному" чтоб все новые плюшки использовать, или от попыток "впихнуть невпихуемое" и неверного выбора инструмента. На С тоже было написано много чуднохо кода, достойного отдельного тома Бхагават-Гиты :)

[eldhenn]

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

[fr0ster.livejournal.com]

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

[sborisov]

По сравнению с плоским Си, там только плюсы.
В чём у вас проблема с этим языком?

[vitus_wagner]

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

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

[max630.net]

> сильно увеличивается ... время выполнения

Ну это как писать. Если не плодить виртуальных объектов - будет как на C.

А для больших систем тормоза от языка слабо зависят. Гном без плюсов не сильно быстрее КДЕ с плюсами.

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

[sborisov]

Это где же Java быстрее С++?
Если выделять память и не освобождать - то конечно всё в шоколаде (опция -server в версиях до java 6.какой-то надо было включать, сейчас по дефолту), но она закончится скоро и тогда запускается GC.
+JIT его время работы считают при измерениях? :) Я думаю нет.

Проблемы со скоростью UI в Java вообще не решаемы.
Поводите быстро курсором мыши по менюшкам в IntelliJ idea
Тот же С# быстрее Java в этом вопросе, но всё равно не успевает.
http://blog.evernote.com/2010/10/26/evernote-4-for-windows-is-here

Где время выполнения увеличивается?
Если вспомнить BeOS (практически полностью написанную на плюсах), так она была очень быстро написана, летала просто по сравнению с Windows, а Linux тогда даже сравнивать с ней было неприлично.
Compiz уже давно как на плюсах переписали -никаких проблем с производительностью нет.
Unity в убунту тоже на С++.
Тот же Кармак проблем не испытывет.
http://fabiensanglard.net/doom3/interviews.php#qc++

[potan.livejournal.com]

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

[mithraen.livejournal.com]

1. Структуры данных. Я вот наблюдаю как в Digium реализуют различную логику для хранения данных, начиная со связанных списков. На препроцессоре C. Феерический бардак получается.

2. Паттерн RAII. Очень удобно, например, чтобы не забывать освобождать локи (если код сильно ветвистый, ошибки с локами очень частые). Существеный процент багов в астериске как раз решают легко этим паттерном.

3. Более жесткая типизация. Конечно, до haskell'а какого-нибудь как до луны пешком, но все же.

4. Перегрузка функций. То, для чего в C чаще всего используют макросы. Например реализация банальных min/max.

В общем если использовать C++ не как считается "правильно", а как 'C с плюсами" то получается очень даже неплохой язык, по сравнению с C.

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

[vitus_wagner]

1. Более ублюдочного способа организации данных, чем C-style структуры, унаследованные С++ я не знаю. Перловые хэши заметно лушче.

2. Lexical scoping вещь, конечно, неплохая. Но этого где только нет.

3. Более жесткая, чем где? И вообще в большинстве случаев типизация ПЕРЕМЕННЫХ в отличие от типизации ЗНАЧЕНИЙ - это зло.

4. Перегрузка функций, а особенно операторов, сделана ровно потому что Страуструп без подобных костылей Obfuscated C context выиграть немог. Понадеялся, что хотя бы Obfuscated C++ выиграет. Ну, блин, использовать оператор логичесокго сдвига в качестве оператора вывода. Если уж хочешь разрешить создавать свой синтаксис, нужно делать это по-человечески, разрешив создавать новые управляющие структуры (как можно в Tcl) и определять свои инфиксные операторы, задавая им относительный приоритет.

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

[max630.net]

> типизация ПЕРЕМЕННЫХ в отличие от типизации ЗНАЧЕНИЙ
А это что, кстати, означает? Я это видел уже где-то, но в чём смысл не понял.

Если надо сделать перемемую не переменной - есть const, тоже кстати неплохая штука, хотя оно как раз есть в C.

[mithraen.livejournal.com]

1. Я думал мы сравниваем C и C++. C++, если не использовать большинство его дурных фич где не надо -- лучше.

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

2. К счастью да. Правда вот даже в Java их -- нет. И вообще в языках со сборкой мусора с этим бывают проблемы. В perl AFAIR хотя бы сборщик мусора инкрементальный, поэтому в нем такая радость работает.

3. Более жесткая чем в C, разумеется.

4. Про ублюдочность iostream можно даже и не говорить :) А перегрузка функций таки нужна. Красивый способ обойтись без нее в обычном виде, оставив все плюшки я вижу разве что в haskell.

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

$ ls -l /usr/lib64/libperl-5.16.so
-rw-r--r-- 1 root root 1615416 Sep 26 04:39 /usr/lib64/libperl-5.16.so

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

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

[mithraen.livejournal.com]

Добавлю, еще есть приложения где существенная часть кода должна быть оптимизирована. Те же web-сервера, или вот тот же Asterisk. Их надо писать на компилируемом (хоть бы и JIT) языке программирования. Причем существенная часть кода там это перетасовка байтиков, и организация более эффективных структур хранения данных.

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

[slobin]

Сдвиг влево в качестве оператора вывода чисто визуально режет глаз. Я понимаю, что Страуструп имел в виду (типа стрелочка такая, "засунь вот это вот туда"), но выглядит ужасно. Зато мне, опять же чисто визуально, весьма нравится вот такое:

#OUT + "x = " + x + "\n";

Казалось бы, сложение здесь ещё менее логично, но дело-то не в логике, а во внешнем виде. Так, стоп, торможу! Это даже лучше, чем я думал! Конкатенация строк ассоциативна, поэтому нет разницы между "сконкатенировать и один раз вывести" и "вывести несколько раз". Данная запись эту эквивалентность отражает, логика на месте (в отличие от сдвига влево). Жаль, язык умер, красивый был. :-(

... Каждая концепция порождает свою фигню ...

[beldmit]

Так и запишем: STL Витус не знает :-)

[vitus_wagner]

От наличия STL и даже boost eval в C++ не появился. Язык без eval высокоуровневым не считается. Так что попытка сделать из С++ язык высокого уровня посредстовм стандартной библиотеки не удалась.

[gegmopo4.livejournal.com]

Зачем тебе eval?

[eldhenn]

Э... вы часто используете eval в других языках? В том же перле?

[mithraen.livejournal.com]

Haskell это не низкоуровневый язык?

[slobin]

А скажи мне (это не риторический вопрос: я совершенно не знаю, как выглядит ландшафт реального софта на этом языке), в реальном коде на плюсах типов "строка символов" всего два или по-прежнему зоопарк? То есть, живые программисты пользуются char* и STL string, или в каждом проекте "строки" свои? С двумя типами я ещё готов смириться: в конце концов, в тех же питоне и эрланге их фактически тоже по два (в обоих случаях скорее по историческим причинам, в обоих случаях по идее есть правила, когда какой использовать, в обоих случаях правила постоянно нарушаются... но, в конце концов, до двух я в своей пещере считать умею, так что хрен с ним! :-)

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

... Навязчивое мудрствование в утренние часы ...

[vitus_wagner]

В любом проекте с историей - зоопарк. В том проекте, над которым сейчас работают я, кроме std::string и char* активно используется TAO_StringManager.

[yurikhan]

В проектах, над которыми мне доводится работать, в основном std::string (когда с ЭТИМ реально нужно работать как со строкой), местами const char* (когда литерал). Но иногда приходится взаимодействовать с библиотеками соседних команд, и там попадаются std::wstring и Qt’шный QString.

[max630.net]

"стандартная библиотека" != "для жизни достаточно". На роль стандартной библиотеки STL вполне тянет, по-моему

> хаскель обречён ровно по той же причине
да, зоопарк строк там уже есть :)

[beldmit]

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

[taelhash.livejournal.com]

Зависит от проекта. В чем-нибудь маленьком вообще ограничиваются std::string'ом, превращая его в const char* только в точке взаимодействия с libc (ибо STL'ное I/O ужасно и вызывает реакцию отторжения, кажется, почти у всех).

В большом многомодульном — ну, я видел, кажется, +3 строки к упомянутым.