vitus_wagner | Плюсы C++

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

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

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

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

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

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

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

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

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

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

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

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

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

А это означает, что переменные - не типизированные. Сейчас хранишь строку, через три строки - число, потом - ссылку на структуру. Или в двух соседних элементах массива хранишь разнотипные значения. А само значение - вполне типизированное. И зачастую ещё и интроспекцию допускает.

Это называется динамическая типизация. Конфетка на любителя, мягко говоря.

> А это означает, что переменные - не типизированные

Угу. Функция ждет, что в параметре строка, а ей прилетает словарь, например.

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

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

... Identical to supernatural ...

Да ладно, куча пхпшных эксплойтов основана на приведении типов.

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

Это не кортежи.

http://www.google.com/search?q=%22object+has+no+attribute%22 , опять же

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++ просто меньшее из зол.

У C еще есть важная ниша -- библиотеки.
Увы, в этом плане C++ практически не лучше perl. Из-за name mangling и рантайма использовать код на С++, например из Tcl получается заметно сложнее, чем код на С.
А также см python-tkinter. Код на Tcl из кода на Python вполне используется.

export "C" никто не отменял.
но -- да, это требует доп усилий.

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

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

Это - заблуждение. Как известно, софт для сотовых коммутаторов, у которых нагрузка такая, что никаким астерискам не снилась, и аппаратные мощности довольно ограничены, пишут на erlang. (И его, собственно, для того и придумали).

Erlang хорош тем, что в отличии от большинства ныне принятых подходов к разработке IP-сервисов не делает тред на каждый сокет (вернее использутся собственные легковесные треды). Благодаря этому если переписать просто втупую какой-нибудь apache на erlang он, в итоге, под большой нагрузкой будет работать быстрее.

Но вот nginx уже так переписать не получится.

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

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

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

А Erlang это пример крайне удачного для своей области разделения обязанностей между низкоуровневым, написанным на C рантаймом и высокоуровнвым скриптовым языком.

На мой взгляд, правильно выбранная пара из скриптового языка и С-рантайма побъет один универсальный среднеуровневый язык, будь то C++, D или Java в любой области. В достаточно сложном проекте, правда, может понадобится более одного высокоуровневого языка.

1. По поводу тредов согласен целиком и полностью. Я, кстати, не знаю ситуаий где они были бы необходимо (и нельзя было бы обойтись shared memory).

2. Если в апач не встраивать языки программирования то он не нужен, ибо есть nginx, который легче и шустрее. Или какой-нибудь lighttpd, если нужен cgi а не fastcgi.

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

4. Про Erlang согласен полностью.

5. Про использование пары C + скриптовый язык также согласен.

C++, как я уже сказал, пригоден как замена C во многих случаях. Именно благодаря тому, что на C++ можно писать столь же низкоуровневые вещи как и на C. А вот высокоуровневые нельзя ни на одном из них. И тот же Perl использовать целесообразнее во многих случаях, в которых сейчас используют C/C++.

P.S. Собственно о чем мы спорим? Мы по всем позициям согласны, кроме одной -- я считаю, что "C++ можно, и часто даже нужно использовать вместо C в качестве 'C с плюсами', если не использовать большую часть его дебильных псевдофич"

Парочка разногласий у нас все же есть.

1. Я считаю что апач имеет смысл в ситуации статика+cgi. И что cgi гораздо правильнее, чем fastcgi. В смысле, если нагрузка на динамическую часть сайта такова, что cgi не справляются, то либо неправильно распределен контент между статикой и динамикой (90% современных CMS), либо проект настолько велик, что все равно нужен кластер. А CGI сильно проще чем fastcgi, поскольку короткоживущие процессы вообще проще программировать и они прощают больше ошибок.

2… Я считаю, что число ситуаций, когда C уже не тянет, и хочется чего-то более выскоуровневого, а прикручивание полноценного второго языка ещё не оправдано - пренебрежимо мало. И вообще начинать разработку любого проекта надо с какого-нибудь высокоуровневого языка, и только потом, когда приспичит, падать на C. Желательно не во всем проекте, а в возможно меньших критических частях.

1. У cgi 2 проблемы:

интертрепатор долго инициализируется;
коннект к некоторым БД (на букву О) ну оооочень долго открывается.

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

(no subject)

vitus_wagner - 2012-10-18 13:46 (UTC) - Expand

(no subject)

phd_ru - 2012-10-18 14:02 (UTC) - Expand

(no subject)

vitus_wagner - 2012-10-18 14:25 (UTC) - Expand

(no subject)

edo-rus.livejournal.com - 2012-10-18 23:21 (UTC) - Expand

(no subject)

vitus_wagner - 2012-10-19 02:04 (UTC) - Expand

(no subject)

slobin - 2012-10-18 21:52 (UTC) - Expand

(no subject)

taris_marh - 2012-10-23 17:28 (UTC) - Expand

(no subject)

eldhenn - 2012-10-19 02:20 (UTC) - Expand

(no subject)

vitus_wagner - 2012-10-19 02:26 (UTC) - Expand

Ну, это почти разногласия, ибо частично я с вами согласен:

По CGI vs FastCGI

1. Противопоставление CGI и FastCGI не совсем корректно, ибо это совершенно разные протоколы для разных целей:
- cgi предназначен для запуска отдельных скриптов
- fastcgi это протокол взаимодействия http-сервера с application server'ом (который, в свою очередь, например запускает скрипты)

2. Самое частое применение fastcgi сейчас -- для замены mod_php. В этом случае php5-fpm играет роль application server'а, который запускает много разных PHP скриптов.

3. Применение такого application server'а оправдано при использовании PHP (да, я в курсе, что использование PHP само по себе обычно неоправдано), так как он в состоянии кэшировать, например, результат парсинга скрипта (у которого может быть стотыщ include).

4. Подход, когда приложение запускающее какой-либо код, и приложение контактирующее со внешним миром соединены друг с другом исключительно через tcp или unix sockets я считаю более правильным, нежели комбайны.

По поводу C/C++:

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

(no subject)

vitus_wagner - 2012-10-18 14:53 (UTC) - Expand

(no subject)

mithraen.livejournal.com - 2012-10-18 17:23 (UTC) - Expand

(no subject)

vitus_wagner - 2012-10-18 17:28 (UTC) - Expand

(no subject)

mithraen.livejournal.com - 2012-10-18 17:33 (UTC) - Expand

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

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

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

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

>Сдвиг влево в качестве оператора вывода чисто визуально режет глаз.

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