Apache, fastcgi и c++: «Hello, world»

C++*
img
Писать web-приложения на C/C++ дело неблагодарное. Многие говорят, что это полное безумие, когда есть PHP и Perl. И я с ними согласен. Это очень просто написать сайт на PHP(особенно используя фреймворки вроде Zend Framework).
Но..(всегда есть какое-то «но»).
Давайте не будем забывать, что простота использования складывается не только из простого синтаксиса. Учитывается множество параметров. И одним из весомых параметров является наличие статей «Get started with ...» с примерами «hello, world»-программ. Я собираюсь добавить немного простоты написанию fastcgi на C/C++. И если прочитав эту статью хоть один человек скажет «А это не так уж и сложно», то я буду считать свою миссию выполненной.

Чтобы пройти весь путь от пустого исходника до надписи на экране браузера, нам придется настроить веб-сервер( в нашем случае Apache), установить на него mod_fastcgi, выбрать библиотеку libfcgi и наконец написать «Hello, world»-программу.

Вступление: FastCGI


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

Веб-сервер


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

Возможные альтернативы:
Nginx и Lighttpd имеют «родную» поддержку интерфейса fastcgi и их использование более предпочтительно на «продакшн»-серверах. Можно также использовать MS IIS.

Mod_fastcgi, mod_fcgid


Мне известно два модуля при помощи которых осуществляется поддержка fastcgi-интерфейса в апаче, это mod_fastcgi и mod_fcgid.
Mod_fastcgi разрабатывается компанией Open Market c 1997года. Последняя версия 2.4.6 была обновлена 13го ноября 2007 и, как уверяют авторы, является очень стабильной.
Mod_fcgi, судя по домену, разрабатывается китайскими программистами. Последняя версия 2.2 датирована 31июля 2007. Отличительными особенностями от mod_fastcgi являются: новая модель управления fastcgi-программами, обнаружение ошибок в работе fastcgi-программ. Модуль имеет бинарную совместимость и поэтому перекомпилировать программы, работающие под mod_fastсgi нет необходимости.
Используя development kit с fastcgi.com для разработки программ, я решил, что более уместно будет использовать mod_fastcgi, т.к. они используют общую библиотеку libfcgi.

Для подключения модуля mod_fastcgi необходимо добавить в httpd.conf:
LoadModule fastcgi_module modules/mod_fastcgi.so
AddHandler fastcgi-script .fcg .fcgi .exe


Типы запуска fastcgi-программ


Используя mod_fastcgi можно запускать программы тремя различными способами: динамически, статически и удаленно.

Динамический способ запуска: В момент начала работы apache создает только process manager(PM), ожидающий входящих запросов. Как только первый запрос получен, process manager создает экземпляр программы для его обработки. В зависимости от настроек, после обработки запроса программа может быть завершена PM’ом, либо может быть использована для обработки последующих запросов. С помощью настроек можно задавать множество параметров создаваемого пула приложений, такие как минимальный и максимальный размер, время жизни приложений, максимальный размер очереди запросов и другие.
Директива: FastCgiConfig option [option ...]

Статический способ запуска: В момент начала работы apache создает PM, который в свою очередь создает заданное количество экземпляров программы для обработки входящих запросов.
Директива: FastCgiServer filename [option ...]

Удаленный способа запуска: Приложение запускается независимо от apache и PM. PM выступает в роли proxy.
Директива: FastCgiExternalServer filename -host hostname:port [option ...]
FastCgiExternalServer filename -socket filename [option ...]


Методы взаимодействия:


  • Stdin
  • Unix domain socket / named pipe
  • TCP Socket

Stdin: Используется при динамическом способе запуска fastcgi-программ. Взаимодействие происходит через Standard in file descriptor.

Unix domain socket / Named pipe: Может быть использован, как при статическом так и при удаленном способе запуска fastcgi-программ. При статическом способе socket создается process manager’ом, при удаленном способе socket должен быть создан fastcgi-программой. Чтобы использовать данный способ необходимо задать параметр –socket имя_сокета.

TCP Socket: Может быть использован также как и Unix domain socket / named pipe, как при статическом так и при удаленном способе запуска fastcgi-программ. Для использования в статическом режиме необходимо задать параметр -port номер_tcp_порта. Для использования в удаленном режиме параметр -host имя_хоста:номер_tcp_порта.

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

Fastcgi libraries


Не так уж и много существует библиотек помогающих создавать fastcgi-программы на C/C++. Наиболее популярна libfcgi.lib, которая поставляется в составе development kit от fastcgi.com. Библиотека, честно сказать, предоставляет небогатый функционал для работы.
Существует также Fastcgi++ библиотека классов на С++.
Так как это моя первая fastcgi-программа, то я буду использовать старую, проверенную библиотеку libfcgi.lib.

Hello_world.fcgi


Программа использует для коммуникации TCP Socket, открывая порт номер 9000. В браузере выводится строка «Fastcgi: Hello, world».
Используемые функции:
int FCGX_Init(void);
— Инициализация библиотеки FCGX
int FCGX_OpenSocket(const char *path, int backlog);
— Открывает слушающий сокет (Параметры: path – имя сокета, backlog – глубина стека запросов).
int FCGX_InitRequest(FCGX_Request *request, int sock, int flags);
— Инициализируем структуру запроса для использования внутри FCGX_ Accept_r (Параметры: request – указатель на структуру запроса, sock – слушающий сокет используемый совместно с request, flags – флаг запроса (доступные флаги: FCGI_FAIL_ACCEPT_ON_INTR – не вызывать повторно accept при разрыве).
int FCGX_Accept_r(FCGX_Request *request);
— Получает новый запрос на обработку.

Полный текст программы:
#include <string>
#include "fcgi_stdio.h"
#include <stdlib.h>
#pragma comment(lib"libfcgi.lib")

int main(int argc, char* const argv[] )
{
    std::string port=
":9000";        //Задаем номер порта TCP
    int  listenQueueBacklog = 400;    //Глубина стека запросов
    FCGX_Stream *in, *out, *err;
    FCGX_ParamArray envp;

    
if(FCGX_Init())    exit(1); //Инициализируем библиотеку перед работой.

    int  listen_socket = FCGX_OpenSocket(port.c_str(), listenQueueBacklog); //Открываем новый слушающий сокет
    if(listen_socket < 0)    exit(1);

    FCGX_Request request;
    
if(FCGX_InitRequest(&request,  listen_socket, 0)) exit(1); //Инициализируем структуру запроса

    while(FCGX_Accept_r(&request) == 0)
    {
        FCGX_FPrintF(request.out,
"Content-type: text/html\r\n\r\n<TITLE>fastcgi</TITLE>\n<H1>Fastcgi: Hello world.</H1>\n");

        FCGX_Finish_r(&request);
//Завершаем запрос
    }

    
return 0;
}



Vhosts.conf


Кусочек файла настройки vhost.conf отвечающий за helloworld.local:
NameVirtualHost 127.0.0.1:80
<VirtualHost 127.0.0.1:80>
  ServerAdmin mail@localhost 
  DocumentRoot «C:/Apache2/cgi-bin»  
  ServerName «helloworld.local»
 
  <Directory «C:/Apache2/cgi-bin»>
    Options Indexes FollowSymLinks MultiViews ExecCGI
    AllowOverride all
        Order Deny,Allow
Deny from all
Allow from 127.0.0.1
  </Directory>
 
  <Files hello_world.exe>
     SetHandler fastcgi-script
  </Files>
 
  FastCgiExternalServer C:/Apache2/cgi-bin/hello_world.exe -host 127.0.0.1:9000
</VirtualHost>

В папке «C:/Apache2/cgi-bin» у меня находится файл .htaccess, направляющий все запросы к helloworld.local на hello_world.exe.

Окончание


Ну вот и все, теперь у меня в браузере гордо высвечивается фраза «Fastcgi: Hello, world».
+76
7 июня 2009, 03:09
116
Sonic_SE 8,0

комментарии (114)

+15
bobry #
а дальше Hello World это в каких нибудь случаях заходит?
+2
xdisa #
Вполне может подойти для случаев, когда критично быстродействие.
+1
Sonic_SE #
ab показывает среднее время выполнения одного запроса при 10 конкурентных около 2,5-3ms. Кажется это не так уж и быстро. Наверное от того что ведется синхронная работа с сокетом.
+3
xdisa #
Я имел ввиду не количество запросов, а время обработки какого-либо одного, но тяжелого, например расчеты и т.д. Или просто какие-то специфичные программы. Например какой-нибудь рендер.
–2
nerezus #
Статья про оптимизацию. Настоятельно советую почитать, чтобы больше не говорить такого.
rsdn.ru/article/philosophy/Optimization.xml
Краткое содержание статьи: «Оптимизировать надо узкие места»
0
gaiver #
Вполне может подойти, когда работать с альтернативой нет возможности.
+4
Sonic_SE #
После «Hello, world» я попробую написать web-интерфейс к своей программе. Писать не так уж и сложно, просто сказывается сильная неразвитость веб-направления на с++ и отсутствие хороших библиотек.
Fastcgi-программы на c/c++ очень похожи по структуре на fastcgi-программы на perl. Можно писать с оглядкой на множество существующих perl-скриптов.
0
rei07 #
я вот посмотрел на все это, и пришел к выводу что это только начало такое тяжелое.
думаю что если был нормальный фрейм форк, как ZF CI и др с кодогенерацией. То время на написания вэб приложений — отличалось не на много.
благо PHP объектно-ориентирован.
+2
Sonic_SE #
После «Hello, world» я попробую написать web-интерфейс к своей программе. Писать не так уж и сложно, просто сказывается сильная неразвитость веб-направления на с++ и отсутствие хороших библиотек.
Fastcgi-программы на c/c++ очень похожи по структуре на fastcgi-программы на perl. Можно писать с оглядкой на множество существующих perl-скриптов.
0
highw #
Насколько мне известно abn.com.ua баннерная сеть с оборотом 11М написана как раз на си… Таким способом или другим, но факт.
0
highw #
… была написана…
0
pROCKrammer #
у меня один знакомый сейчас пишет интернет магазин на С++.
+3
odessky #
Если уж и писать на сях то сразу модуль в nginx
+23
Sonic_SE #
А если пишете десктоп-приложение, то сразу как расширение ядра ос?
+4
kex #
Здесь другая аналогия. Десктоп приложение, если говорить об оконной части, не имеет смысла лабать на чем-то хардкорном. А вот критичные к производительности места, вполне себе могут быть и на уровне ядер.

0
edy #
Я тоже, когда «пробовал» писать что-то для веб на С/С++ писал модуль для apache. Хотя я не вспомню сейчас как там что, но у меня такое ощущение, что для хелло ворлд у меня гораздо меньше строк получилось )

Меньше кода — меньше ошибок © )
+4
ruzzz #
Есть ли какие-нибудь фреймворки на C/C++?
+2
Sonic_SE #
Полноценных я не нашел. можно внимательно присмотреться к www.nongnu.org/fastcgipp/.
cryp.to/publications/fastcgi/#FRAMEWORK — здесь были намеки, но опять же реализации в сети я не нашел.

кстати, когда я написал точно такой же комментарий в другом топике, то надо мной долго смеялись. Теперь я не один. =)
0
ruzzz #
Возможно смешно звучит слово «фреймворки» :)? Наверное правильней было бы спрашивать о библиотеках и утилитах, облегчающих программирование под Web на С/С++?
+2
Goodrone #
+2
nwalker #
Klone, мини-фреймворк для С. Изначально предполагался для веб-интерфейсов к какому-либо железу/прочему лоулевелу. Довольно забавная штучка.
0
haikuos #
а если без сокетов?
0
Sonic_SE #
Есть вот такая табличка по соотношению способов коммуникации и типов запуска программы:

STDIN Domain Socket TCP/IP Socket Remote app PM starts app

External N Y Y Y N

Dynamic Y N N N Y

Static N Y Y N Y

без сокетов можно использовать только динамическим способом запуска, при этом поток stdin указывается при порождении процесса программы.
Если вы спрашивали о скорости работы, то я не знаю, должно быть быстрее.
–19
ISpy #
Ээто безусловно интересно но… Вряд ли когда-нибудь буду на С/С++ писать сайты, слишком уж это. Вот на ассемблере — это да, сила! Зачем нам полумеры :E
–7
ISpy #
Хотя на счет того, что не буду на сях писать сайты, это я погорячился. Более правильно сказать — fastcgi вряд ли буду юзать, а вот под.нет возможно и придется в определенных местах использовать C++.

Где-то я видел графики сравнения по скорости между php, perl, ruby, cgi, еще чего-то. Если кто-нибудь поделиться — буду благодарен. Интересно.
–5
ISpy #
Интересно в карму насрали любители С++ или не-любители ассемблера? :) Хотя вроде ни то ни другое не опускал и не пропагандировал
+6
ecl #
я думаю не-любители комментариев не в тему
+3
ISpy #
Да вроде комментарий в тему — я высказал свое личное мнение, что вряд ли буду создавать сайты используя С++. Хотя наверно не стоит обсуждать подобное, вот это точно будет не в тему :) И меня скорее всего будут бить, может быть даже ногами © G.
–5
Alexion #
называется мы не ищем легких путей, обычные сайты: блоги, магазины, корпоративные — php за глаза, а еще есть asp.net, java.
+1
Kirk #
Можете ли привести пример сайта написанного на С++, хотя бы частично ?? Просто интересно посмотреть.
+2
walker #
ebay.com — ключевые сервисы написаны на С++
0
Smerig #
Ну там больше ISAPI, чем фастги :)
0
FloppyFormator #
Мне когда-то говорили, что мэйлру относится к таковым. Частично на С/С++, частично на перле.
0
INIT #
все верно, позволяет очень ощутимо экономить железо
0
iliich012 #
А по времени наверное намного затратней. Хотя могу ошибаться и это не аргумент за другии языки.
0
IDDQD #
Практически все веб-сервисы реального времени — voip конференции, некоторые онлайн игры и т.п.
+1
Lux_In_Tenebris #
Какое отношение это имеет к веб-сервисам и HTTP протоколу?
0
Zharskiy #
веб-чаты не видел никогда чтоли?
сейчас уже есть звонилки, типа позвоните нажав на кнопочку и поговорите с нашим оператором прямо из браузера
0
Lux_In_Tenebris #
про C++ и его отношение к разработке веб-приложений выше, полагаю, вы не читали даже…
0
sigizmund #
Yahoo! Placemaker. Это сервис, вообще говоря. Back-end написан на C++ целиком и полностью.
0
vectoroc #
paypal.com вроде на с++
0
sergey_novikov #
Например, баннерные сети, счетчики. Только основная часть, т.е. выдача рекламного блока/картинки, но не сайт. Работает быстро.
0
midday #
ЭМ… А На чем написан Google? О_О
+1
ISpy #
Помню когда-то давно задавал вопрос людям из русского гугла, кажется они упоминали что сидят под каким то линуксом и пишут на питоне, С++ ну и еще чего-то по-мелочи. Не все конечно, но очень многие.
+2
zw0rk #
На дофига чем написан гугл :)
0
nwalker #
Несложная, непопулярная, но потихоньку развивающаяся браузерная игра — tuagir.ru, написана на С под фреймворк Klone.
–1
max_m #
наверное именно поэтому она "_ потихоньку_ развивающаяся браузерная игра" :)
0
zw0rk #
Какие-то критически важные части LinkedIn, афаик, на Ц.
0
joymax #
proza.com.ua
на С частично
0
maserg #
что именно там может быть на С частично?
0
maserg #
а, я кажется понял…

вот сайты:

Call of Duty 2 в Украине
и
Call of Duty 4 Modern Warfareв Украине
и
Call of Duty 5 World at War в Украине

они все полностью на С-- + немного asm
0
dmtrrr #
mp3.ru
+3
torkve #
Имхо, в большинстве случаев это совершенно не нужно. Гораздо проще и удобнее использовать точку входа на каком-нибудь пхп, а сишный или плюсовый код оформить подключаемым к php расширением. В память оно будет загружаться одновременно с апачем, обработка ввода и показом результатов будет заниматься php. А C/C++ будет заниматься ровно тем, чем должен: обрабатывать переданный набор данных и возвращать результат. Заодно это, как правило, даёт универсальность — одну библиотеку можно будет при необходимости использовать и из плюсовой программы, и из php, и еще откуда.
0
Carry #
Если ради скорости на C++, то лучше вообще без apache.
Правда, тогда кроме C++ на занятый порт ничего не прикрутишь (резко сложность возрастает).
0
Tagire #
В принципе статику можно любым другим сервом, висящем на другом порте, отдавать. А вообще в данной ситуации лучше к nginx прилепить и не париться.
+1
Mox #
Большое спасибо за статью. :)

Прочтя статью, до меня вдруг окончательно дошло, что такое FastCGI. И если вы тут предлагаете попробовать C++, то у меня возникло желание попробовать FastCGI + Java.

В какой-то момент деплой в сервлет контейнер, какие-то его падения и прочее стали просто задалбывать и занимать ощутимое время разработки. Окончательно разозлившись, я свалил на Ruby On Rails, чему очень рад.

В голове уже идея простого фреймворка аля RoR для Java. FastCGI + DB4O + еще что нибудь ;)

Но после прочтения статьи появилось желание попробовать, за что респект.
0
zw0rk #
> В голове уже идея простого фреймворка аля RoR для Java.

Вас уже опередили. См. grails.
0
Mox #
Ну тогда уж можно было бы вспомнить про JRuby + Rails, все это отлично работает.

Нет, я имел ввиду не платформу, а язык.
–6
SarganSaor #
Видел веб морду к базе данных написанную на C… При переезде на другой сервер отказалась работать… хорошо еще что программист был доступен, скинул исходники, и только после перекомпиляции заработало. Кстати и собиралось тольк gcc 2.96, другие уже с ошибками валились… Ужос в общем. Не и интерпретаторы не для интернета.
+1
Paul #
Написать через задницу можно на любом языке. Скажите спасибо своему программисту, Си тут ни при чём.
0
akick #
Очень интересная, по крайней мере для меня, тема.
Был бы признателен за продолжение темы.
+3
sigizmund #
Спасибо за статью. На практике, из моего опыта, могу сказать, что чаще всего C++ не используется непосредственно как CGI front-end. В одной из крупных интернет-компаний ;) применяется обычно следующее решение: в качестве фронт-энда выступает PHP код, который выполняет задачи связанные с авторизацией пользователей, начальным sanity check входных данных и т.п. Следующим компонентом идет прокси-модуль, который как правило, представляет собой расширение для PHP, которое уже непосредственно перенаправляет запросы к .so, в котором заключен высокопроизводительный С++ код. Это немного более громоздкое решение, но в долгосрочной перспективе оно работает лучше, т.к. все компоненты на своих местах и для каждой задачи мы используем наилучшим образом подходяющую технологию.

В частности, на подобной архитектуре построен Yahoo! Placemaker — наверное, я все же описал с массой ошибок, но в целом архитектура именно такая.
+1
ISpy #
Поискал тесты производительности, да C++ все таки рулит:
elliottback.com/wp/ruby-vs-php-performance-revisited/

izumi.plan99.net/blog/index.php/2008/01/17/ruby-vs-php-performance/
+1
ISpy #
Ну вот, глюк случился, продолжение сообщения:

www.wrensoft.com/zoom/benchmarks.html

Приведенные материалы конечно не являются истиной в последней инстанции, но более-менее картину можно представить. Да, С++ (CGI) рулит, но ему хорошую конкуренцию составляет .NET, и даже Руби приближается к нему по производительности, причем ближе многих (v1.9). Так что все таки стоит задуматься, а стоит ли использовать С++ для такой области как веб, учитывая что он не очень к этому приспособлен. Это не критика С++ никоим образом :)
0
midday #
Да стоит задуматься. Но очень рад, что есть такая возможность для его использования. Это дает всю мощь Си ++ =) (бесспорно я думаю), без которой порой пока очень сложно обойтись.
–1
midday #
И еще. По бенчмаркам ASP.NET отстает от CGI на примерно 30%. Согласитесь это не мало.
+1
ISpy #
Да, но по сравнению с другими участниками теста —.нет молодец :)
И еще — С++ вроде оптимизировать особо некуда больше. А в .NET постоянно выходят новые версии этого фреймворка, что я думаю положительно сказывается на производительности, может он когда-нибудь приблизится к С++.

Хотя скорее компьютеры просто станут еще на порядок мощнее и веб-разработчики забудут о разнице в производительности разных языков и технологий и будут писать на чем им удобнее :)
–1
midday #
Да. Вот с этим согласен. ( «на чем им удобнее» ). И согласен с тем что «приблизится».
Ждем новой эры. Я думаю новая эра придет только когда операционные системы станут сами объектно-ориентированны… А в MS всё на стареньком Win32 как сидели, так и сидят.
0
Smerig #
Ну вебформс — это не все, на чем пишут странички в асп.нет :)
Попробуйте те же асинхронные хендлеры. Нет надобности создания экземляров класса Page, прикручивания событий. Плюс Thread Pool. Да, а еще можно создать один экземпляр хендлера, в некотрых случаях это тоже может сказаться на производительности в лучшую сторону.
0
egorinsk #
Странно. а я слышал наоборот, Руби очень медленный. Например приложение на RoR приходится запускать заранее, так как иначе ответ на запрос был бы слишком медленным (а вот php работает быстрее!)
0
ISpy #
На сколько я знаю, и в тестах заметно — руби достаточно быстрый (особенно >v.1.9), а вот Ruby on Rails не самый быстрый из фреймворков, поэтому неторопливость RoRа переводят на язык, но под руби есть и другие фреймворки. То есть нельзя говорить про приложения на RoR и PHP — пхп это язык, а RoR — фреймворк. Можно сравнивать руби и пхп, что в тестах и делают.
0
Becoming_Insane #
источникик конечно очуметь, тока вот первая ссылка — вобоще 2008-ой год )
+2
mocksoul #
ну уж если С/C++, то тогда mod_helloworld… Благо апач с его apr — очень грамотное апи, не хуже чем и сам fastcgi протокол (всмысле, не сложнее). А выигрыш в скорости в таком случае совсем фатальный)
+1
mocksoul #
да и, не могу не заметить: современные маленькие дилетанты только думают, что «ну уж если веб то только интепретируемое...». Люди с мозгами знают что для некоторых задач си и 2 сервера лучше чем питон/пхп/чтоугодно и 20ть. Просто для бОльшего круга задач в этом смысла нет.
+1
akzhan #
Де факто я знаю проекты, где от сервера с C++, перешли к ферме серверов с интерпретируемым кодом.

Потому что машины дешевы, а саппорт C++-проекта оказался дороже, чем саппорт более медленного кода.
–1
mocksoul #
ну я же говорю — люди с мозгами…

С/C++ кода в мире больше чем какого-либо другого. И ниче, поддерживают…
0
viperrsh #
Веб-приложения на С`ях, тоже самое, что GUI приложения на php — можно, а нужно ли...?! Быстродействие — так настроем сервер, отключим все что не нужно — будет вам реактивная ракета…
А Вам, уважаемый автор, спасибо за статью :)))
0
midday #
Может не «настроем сервер» а купим новый?
+2
ISpy #
Я вот несложные GUI-приложения пишу на javascript в .hta :-[
Зачастую это бывает намного продуктивнее и быстрее, чем открывать студию и ваять что-то там — кода получается меньше и делаю я это быстрее :) А на счет С и пхп — всетаки С более универсальный, и если гуи на пхп — зло, то вот в веб С живет потихоньку.
+2
Popik #
Если уж в коде используются сокеты, то не легче/оптимальнее ли будет писать сразу без апача, используя самописный веб сервер? Ведь его написать это совсем несложная задача.
+3
alrond #
А можно и не самописный, а например такой
0
Popik #
Классная вещь. Спасибо за ссылку.
0
borisko #
Если мы будем писать отдельный web-сервер, то нам надо будет еще заморочиться:
1) с отдачей статических файлов
2) с безопасностью
3) с различными фичами, вроде access по ip, паролированием, рерайтами.

Оно нужно? :) С этим прекрасно справляется nginx.
+2
egorinsk #
Проблема в том что на си очень сложно 1) управлять памятью (надо делать умные указатели, так как обычные сборщики мусора плохи. а хороший вам никто не даст просто так, хотя именно на сервере тормоза из за сборки мусора не особо критичны) 2) Вырвиглазный синтаксис: надо писать заголовочные файлы в доп-е к обычным, кучу инклюдов и определять функции до (!!!!!!!) их использования. 3) тяжело писать ажурные конструкции из обхектов, ассоциаьтивных массивово и порчего, как в php. Вам придется самому реализовать такие объекты как хеши.работу со строками, подсчет ссылок… и все только ради того чтобы понять что вы сделали аналог php?

Хотя идея повысить производительность мне нравится. Интепретатор php тормоз, может инклудить файл дольше 1 мс и вообще мог бы работать и побыстрее!!! Жутко злит в общем.
+2
Tagire #
Насчет структур данных кагбэ stl. Да и boost тоже есть. C++ же не первый день существует, очень многое уже давно написано.
0
egorinsk #
И вы считаете, что в Си такой же простой и приятный синтаксис для объектов/массивов как в php? И проблема управления памятью по прежнему остается))

А вот на языке типа D (конечно в нем пара мест тоже неидеальны например работа со строками)  — было бы интересно попробовать писать придложения :)
0
ruzzz #
Ну понятно же, что все зависит от поставленных целей и требуемого соотношения производительность/сложность разработки.
+1
Skara #
Более низкоуровневая работа с памятью — цена за быстродействие и отличительная особенность языка, а не проблема.
0
egorinsk #
Нет, эта проблема (работа с памятью) должна решаться, частично компилятором (так как в части случаев он видит, где память можно уже освободить), частично каким-то средством вроде считалки ссылок, или сборщика мусора.

Так как писать вручную все эти выделения паямти и освобождения надоест быстро.
0
Sonic_SE #
Поверьте, никто кроме автора не разбирается в том как должна работать его программа. если память где-то уже можно освободить, то автор должен это сделать. каким образом это произойдет неважно, будет это явное освобождение памяти или из стека будет вытолкнута переменная неважно. именно автор должен все учитывать и контролировать, а среда и компилятор ему подсказывать и помогать.

как говорил вирт, для написания программ дебагеры не нужны, если она написана правильно.
0
egorinsk #
Это на словах так, автор все знает, а на деле над проектом работает куча людей, следствие баги с памятью, возьмите список уязвимостей в Windows например.

Это просто, когда у тебя в программе 3 функции (и то, мне бы стало лень руками писать delete, я бы навернг придумал что-нибудь, чтобы не писать), а когда огромное количесттво объектов, получаектся ерунда, программист не пишет код а только отслеживает баги.

Единственный способ борьбы с багами памяти — автоматическое управление памятью.
0
Sonic_SE #
Чтобы не писать delete, средство уже придумано.
Вы правы виндовс довольно сложный программный продукт у которого были обнаружены множество ошибок при работе с памятью. именно поэтому в майкрософте постоянно усовершенствуют процесс разработки и требования к коду.

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

все моменты неправильной работы с памятью должны быть выявленны на этапе компиляции программы, но не вовремя её работы.
0
egorinsk #
> именно поэтому в майкрософте постоянно усовершенствуют процесс разработки и требования к коду.

А надо — менять особености языка, или применять автоматическое управление памятью. Например, у меня на php ни разу программа не вылетала из-за багов с памятью.

Средства есть, не только сборщики мусора, но и умные указатели например.

> все моменты неправильной работы с памятью должны быть выявленны на этапе компиляции программы, но не вовремя её работы.

Это невозможно, так как неизветсно, сколько раз выполнится какой то цикл, по какой ветке пойдет выполенние, сколько раз будет вызвана функция.
0
allter #
> Единственный способ борьбы с багами памяти — автоматическое управление памятью.

И как это помогает при зацикливании структур данных?
0
egorinsk #
Сборщики мусора удяляют зацикленные структуры. счеткики ссылок — нет, но там можно применять хитрости, вроде слабых ссылок, или еще чего-нибудь.
0
allter #
Я в курсе, я имел в виду не совсем это (неверно выразился). Я про то, когда дизайн программы такой, что на какую-то мутную структуру остаётся всегда одна ссылка — например, из замыкания незаконченной процедуры или, более часто, из неаккуратно очищенного глобального или рано-инициализируемого контейнера.

Иными словами, автоматическое управление памятью не спасает от утечек памяти, вызванных кривым дизайном программы.
0
egorinsk #
Понтяно, что с кривыми руками трубно бороться — но можно, например, ограничивая выбор возможных конструкций програмистом. Я где-то выше писал, хорошо бы компилятором отслеживать такие ситуации, то есть в функции типа:

{
a = new Object();
dosmthWith(a);
// здесь компилятор может смело ставить delete a;
… много кода, не использующего a
return true;
}

Уничтожать локальную переменную a можно раньше выхода из функции.
0
allter #
Всё равно лучше программиста никто это не отследит. Разве что ввести в сигнатуру dosmthWith свойство переменной a, которая подскажет, что эта a нигде не будет использоваться, типа:

dosmthWith( unlinkable<Object *> a ) {… }

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

В общем, много моментов. Гораздо проще, если речь идёт о C++ договориться всегда удалять объекты по указателям, определённым в текущем блоке, в этом же блоке, а в классе — в деструкторе этого класса. А для создания структур пользоваться обёртками в виде адаптирующих функций или классов.
0
allter #
P.S. Пример в бесшаблонном стиле:

dosmthWith( Object * unlinkable a ) {… }
0
egorinsk #
Нет, вы не поняли. Я предлагаю уничтожать не объект, на который указывает «a», а только саму переменную, которая удерживает ссылку на него и не дает сборщику мусора удалить объект. Если где-то в функции doSmthWith() кто-то создает новую ссылку на объект, он не будет удален.

Естественно, речь идет о системах с подсчетом сылок или сборщиками мусора.
0
allter #
А, я думал, что вы написали на С++, где приведённая вами конструкция удаляет объект (ссылку-переменную со стека компилятор и так удаляет).

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

Но, как я раньше писал, это не спасает от мемликов за счёт подлинковывания из общих структур… :(
0
tname #
А это не так уж и сложно
0
tname #
А это не так уж и сложно
0
zw0rk #
Хелловролд-то? Конечно. :)
0
Sarius #
Спасибо автору за статью, т.к. очень не люблю фреймворки и все же очень надеюсь на то, что кто-то еще что-то пишет сам. Насчет того, нужно ли подобное, скажу да, т.к. сам лично сталкивался с ситуациями необходимого взаимодействия через веб-интерфейс с драйвером устройства на низком уровне, вот там-то как раз очень-очень и пригодилось сишное приложение.
+1
nitrexin #
пару слов про nginx. он поддерживает технологию fastcgi, но здесь придется использовать либо встроенный в php сервер fastcgi либо ставить стороний обработчик запросов, например lighttpd. я лично так и сделал, потому что первый жрет достаточное количество памяти, а из последнего выдрал утилиту spawn-fcgi, которая и занимается обработкой запросов.
0
bat #
А как с обработкой параметров?
0
Sonic_SE #
разрабатывать свои или брать готовые классы-парсеры параметров запроса.
например bp cgicc или fastcgi++.
0
kashey #
А как с рестартом fcgi через 1000 запросов?
Чувство у меня такое что fcgi не умеет рестартить чилдов ну никак :(
0
Sonic_SE #
MaxRequestsPerProcess n (-1)
0
brainfucker #
Почемуто не компилится пример, пишет:
g++ -o init.bin main.cpp
/tmp/cc7XKvnp.o: In function `main':
main.cpp:(.text+0x47): undefined reference to `FCGX_Init'
main.cpp:(.text+0xab): undefined reference to `FCGX_OpenSocket'
main.cpp:(.text+0xd2): undefined reference to `FCGX_InitRequest'
main.cpp:(.text+0xfb): undefined reference to `FCGX_FPrintF'
main.cpp:(.text+0x107): undefined reference to `FCGX_Finish_r'
main.cpp:(.text+0x113): undefined reference to `FCGX_Accept_r'
collect2: ld returned 1 exit status

Хотя development kit встал нормально…
0
brainfucker #
Судя по гуглу проблема не редка на линуксе, зато нашёл вот эту библиотечку http://cryp.to/libfastcgi/
0
Sonic_SE #
проверьте включение .h файла и библиотеки.

компилятор говорит что функции не найдены на этапе компиляции, значит он даже не нашел их объявления в .h файле.
0
alexol #
Делается это так:
g++ -o init.bin main.cpp -lfcgi++

т.е. указать что использовать либу для С++ если для С то без ++
Если после компиляции запустить и начнет ругаться на отсутствие либ, просто пролинкуйте их т.к. fcgi инсталится в /usr/local/lib

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.