Плюсы C++

[vitus_wagner]

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

Comments

[mithraen.livejournal.com]

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

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

[vitus_wagner]

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

[mithraen.livejournal.com]

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

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

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

[vitus_wagner]

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

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

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

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

[mithraen.livejournal.com]

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 с плюсами', если не использовать большую часть его дебильных псевдофич"

[vitus_wagner]

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

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

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

[phd_ru]

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

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

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

[vitus_wagner]

1. Ну, это зависит от интерпретатора.
2. Эту проблему я решал еще в прошлом веке посредством отдельного процесса-брокера запросов к БД. Для того, чтобы держать пул постоянно открытых коннектов, совершенно не нужно держать в памяти интерпретатор того, что генерирует страницы и кучу байткода, который плохо совместим с COW.

[phd_ru]

2. Т.е. ты просто разделил web application server на постоянную и подгружаемую части. Тоже решение. (-:

[vitus_wagner]

Вообще-то это общий принцип. Если какая-то часть кода требует существенно более трудоемких технологий разработки, эту часть кода надо минимизировать. Именно поэтому, не надо писать весь проект на C, если в 90% проекта нас устраивает производительность python. То же самое касается и персистентности.

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

[edo-rus.livejournal.com]

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

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

[vitus_wagner]

mod_perl в апаче.

[slobin]

Ну, первую проблему я тоже в прошлом веке решал. И с тех пор неоднократно видел это решение переизобретённым с точностью чуть ли не до разделителей строк. Уж больно очевидная идея, всем в голову приходит. А зачем нужен заметно более сложный fastcgi, я так и не понял. :-(

... Новая кожа змеи повторяет узор вековечный ...

[taris_marh]

Для того, чтобы не тратить время на инициализацию framework, как это происходит с разными CMS, если коротко.

В конторе, из которой я ушёл месяц назад, додумались уже до того, чтобы повесить в автозагрузчик классов механизм для отслеживания, какие файлы подгружаются на каждой странице (не считая идентификаторов объектов), и склеивания этих файлов в один такой псевдокэш. Потому что иначе сначала файл грузится, комптлируется, потом начинается подтягивание подключенных файлов, для которых операция повторяется. А иногда подгрузка начинается уже на этапе выполнения. Кроме того, инициализация всего этого кода с залезанием в базу данных.

В общем, муторно и дорого. А с FastCGI получается фишка вроде Tomcat-а с сайтом на Java, но на базе обычного web-сервера и отдельной программы, не претендующей, в отличии от приложения на Java, на то, чтобы стать частью этого самого сервера. Так, например, сделано в Python+Django.

[eldhenn]

Прошу прощения, COW это?

[vitus_wagner]

Copy on write

[mithraen.livejournal.com]

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

По 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 и более удобных способов создания специфических структур хранения данных в памяти.

[vitus_wagner]

Често сказать, не понимаю зачем нужна такая сущность, как application server. Зачем нужен сервер БД - понятно. Он обеспечивает общий доступ к данным,блокировки, транзакции etc.

Зачем нужен web-сервер - понятно. Он на 80-м порту слушает.

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

Но зачем нужно оформлять в виде единой сущности набор бизнес-процедур, сидящй между веб-сервером и БД - мне непонятно.

Toolbox-ы рулят.

[mithraen.livejournal.com]

1. Задача web-сервера -- быстро раздавать файлики, которые он получил либо с диска, либо откуда-то еще.

Задача AS -- исполнять код. Который, во многих случаях, может быть написан либо далеко не хакерами, либо хакерами (в плохом смысле этого слова).

В случае с виртуальным хостингом это очень существенно.

А особенно интересное начинается в тех случаях, когда не просто один IP-адрес, а один домен обслуживается несколькими командами разработчиков. В том числе -- сторонних. Вполне логично изолировать их друг от друга.

2. Собственно раздача файликов, если пользоваться nginx, упирается только в диски, память для кэша, и сеть. Поэтому если у нас всего лишь 1 гигабитный линк, то нам достаточно максимум двух web-серверов (frontend), в HA-кластере.

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

Использование web-сервера, выполняющего одновременно функции application server потребует установки отдельного балансировщика. И, если мы делаем так, то... в итоге мы получаем тоже самое, разве что статика отдается не frontend'ом а backend'ами, а в остальном backend'ы и становятся теми самыми application server'ами, только взаимодействую с frontend'ом по HTTP а не через FastCGI.

Итог -- без FastCGI обойтись можно, а вот без applicatino server'а на больших инсталляциях -- не очень.

[vitus_wagner]

Вообще-то у нас в сервере уже есть одна сущность, которая умеет выполнять код, разграничивать полномочия и т.д. Называется операционная система. Зачем нужна ещё одна сущность, которая делает примерно то же самое. непонятно.

[mithraen.livejournal.com]

Эта сущность нужна чтобы транслировать понятия конфигурации (url -> executable), и заодно протоколы.

Может мы о разных вещах? AS в том виде, как они есть в Java мире обычно не нужны.
AS в стиле какого-нибудь php5-fpm нужны, если нам нужно запускать PHP-код относительно быстро, удобно и безопасно (насколько это возможно для PHP-кода).

А добавив мысль из предыдущего обсуждения -- вот есть люди, которые web-сервисы пытаются на erlang делать. Им тоже следует использовать CGI? Там как раз архитектура получается ну очень похожа на то, что обычно делают жабакодеры.