С(С++) как замена PHP

Ну у PHP, Perl, Python есть один общий плюс для WEB - они интерпретируемы. Впринципе, конечно, никто не мешает использовать и C++ через CGI, ну или забубенить какой-нибудь mod_c++, но это всё-таки оверхед.

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

Пиши сайт сразу в виде модуля под апач :)

Будет крайне быстро, но неудобно обновлять.

Ты болен.

напиши на С++ екстеншн к РНР :)

>Я не сталкивался с WEB-программированием. Теперь пришлось. И я на распутье. Или вникать в достаточно новый PHP или я смогу свои навыки в C++ применить в этой области?

писать на чистом пхп дело гиморное, под него уже написано много чего, имеются фреймворки, на с++ я ничего подобного не видел, так что это принесет массу проблем

зы ну и еще пхп имхо вообще не лучший выбор, взгляни в сторону python и ruby, для них есть очень неплохие фреймворки и языки удобней php

Никаких проблем в принципе нету. Пиши на C++ под ASP.NET

PS Вообще, все зависит от того, что конкретно тебе нужно. Основные либы для веба на C++ есть. Так что если нужно написать что-то не очень сложное, то можно и на чистом C++ + что нибудь вроде FastCGI. Иначе, PHP будет неплохим выбором. Python тоже конечно можно, но комьюнити у него намного меньше чем у PHP, да и для веба в более-менее приличных масштабах он начал использоваться сравнительно недавно, так что есть вероятность, что придется самому искать решение некоторых проблем.

Вообще, все же советую взглянуть в сторону ASP.NET

Всем спасибо за ответы!

Вы очень помогли мне сориентироваться в новой для меня области.

криво написанная на с++ программа может запросто повалить сервер. криво написанная с++ программа может запросто сожрать все ресурсы. криво написанная с++ программа -- потенциальные мемлики. от всего этого защищены интерпретируемые языки.

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

у админа моск далеко не всегда включен особенно насчет cgi. а нативное приложение действительно контролируется намного хуже во время выполнения вебсервером. бомбу на с++ гораздо легче сделать чем на том же пыхе.

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

Limiting Resource Usage

http://httpd.apache.org/docs/1.3/server-wide.html#resource

И никаких проблем с cgi.
Хотя конечно когда оно в виртуальной машине, то контролируется легче. Но.... ява для формы отправки письма как то слишком.

А почему не используется с/с++ ответ на самом деле банален - стоимость. Стоимость разработки и поддержки приложения на плюсах намного выше. А в 99.9% случаев производительности при использовании скриптового языка хватает.

был такой, и я его автор. Находился по адресу
http://carrot.cern.ch
планирую до конца года взобновить проект.
Если интересно сотрудничество: Valeri.Onoutchine@cern.ch

>криво написанная на с++ программа может запросто повалить сервер
там был реализван automatic garbage collector

обьясняю приемущества перед PHP:
1. возможно самое главное, то что C/C++ скрипт может быть
скомпилирован, что значительно упрощает процесс отладки.
Более того, скомпилированный скрипт может быть выполнен
в бинарном виде. За счет чего достигается на порядок большее
быстродействие относительно PHP и других скриптовых языков.
2. гараздо лучшая расширяемость. По идее любая DLL lib доступна.
3. сам C/C++ код может быть использован не только для web programming,
но и в других местах (например, database logic) ... и наоборот.
4. возможна отладка вне web servera.
5. возможна работа непосредственно с железом, системой,
что интересно для встроенных систем.
6. и т.д. - это только немногое, что приходит в голову.

>Ну у PHP, Perl, Python есть один общий плюс для WEB - они >интерпретируемы.

C/C++ интерпретатор давно существует и активно развивается:
http://root.cern.ch/twiki/bin/view/ROOT/CINT
есть надежда, что он достигнет "легкости" TCL.

>обьясняю приемущества перед PHP:

>1. возможно самое главное, то что C/C++ скрипт может быть скомпилирован, что значительно упрощает процесс отладки.

Интерестно звучащая фраза. Почему то считалось что совсем даже наоборот. Без бубна в общем случае фиг отладишь(ну прострипать там, пооптимайзить компилятором если).

>Более того, скомпилированный скрипт может быть выполнен в бинарном виде. За счет чего достигается на порядок большее быстродействие относительно PHP и других скриптовых языков.

С/С++ скрипт - наверное неверное выражение. Бинарный код будет точнее. Конечно он быстрее, но чтобы сделать 3 запроса из базы и отобразить результат большой производительности и не надо. А это сценарий 90% веб приложений.

>2. гараздо лучшая расширяемость. По идее любая DLL lib доступна.

Как правило большинство популярныйх скриптовых языков позволяет подключать через врапперы любые либы.

>3. сам C/C++ код может быть использован не только для web programming, но и в других местах (например, database logic) ... и наоборот.

database logic на с++ - это жесть :)

>4. возможна отладка вне web servera.

Вынужден вас огорчить, кроме АСП наверное все другие языки можно "вне веб сервера" отлаживать.

>5. возможна работа непосредственно с железом, системой, что интересно для встроенных систем.

Это конечно плюс, но нужен ли он автору топика?

>6. и т.д. - это только немногое, что приходит в голову.

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

Хинт: на пхп/перле это буквально пара-тройка часов. Если использовать какие то фреймворки то меньше.

1.
> Интерестно звучащая фраза
Современные компиляторы (GCC4, VC7) настолько продвинутые,
а с ними существует такое колличество tools (gdb, valgind , profilers),
IDE (Kdevelop, VisualStudio), которые позволяют легко
находить синтатические ошибки, оптимизировать код и
"упрощает процесс отладки".

> А это сценарий 90% веб приложений.
думать надо "ширше", например, как это сделал в недавнем прошлом google.


2.
> озволяет подключать через врапперы любые либы.

я говорю о том, что в моем случае, это может делать
"с пол-пинка" любой пользователь, с любой lib,
а не ждать, когда выйдет новая версия PHP,
с новыми PHP extensions.

3.
> database logic на с++ - это жесть :)

database logic на JDBC - это не тоже самое?
даже Oracle имеет свою C++ wrapper lib.

4.
>Вынужден вас огорчить
не надо меня огорчать, я знаю php, mod_perl, etc. "изнутри",
как apache modules developer.

5.
> но нужен ли он автору топика?

про автора топика не знаю, но уверен, что таких
желающих найдется много (я один из них).
Сейчас "оживляю" одну железяку (http://www.kip.uni-heidelberg.de/ti/DCS-Board/current/)
на ней стоит "boa webserver".
Я с удовольствием хотел бы иметь к ней active GUI web interface.

6.
>кажем простенькую страничку ...

несомненно, главным приемуществом PHP является наличие огромного
колличество написанного софта, всяческих заготовок и пр.
Одна из моих идей написать php2c translator используя тот же самый
Zend-engine (ведь именно это он и делает, в конце концов).

А вообще-то, спасибо :)

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

Если я верно Вас понял - то осноаные тезисы, вытекающие из обсуждения:
1. Более-менее распространенные вещи лучше делать на PHP - под них есть куча готовых наработок.
2. Что-нибудь оригинальное - можно писать на том, что лучше знаешь.



>> 5.
>> > но нужен ли он автору топика?
>> про автора топика не знаю, но уверен, что таких
>> желающих найдется много (я один из них).

В моем случае нужно взяться за серверную часть онлайновой игрушки. Как в таком случае будет звучать ответ на вопрос C ws. PHP?

И еще вопрос. Хостинг на OnSmart.net (если это важно) - работает ли он со скриптам(или если оно написано на С - уже называется не скрипт?), написанными на С? Насколько часто у хостеров есть поддержка таких скриптов? Это обычно включено по умолчанию или с ними нужно "списываться" и просить активировать?

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

1. >> Интерестно звучащая фраза

>Современные компиляторы (GCC4, VC7) настолько продвинутые, а с ними существует такое колличество tools (gdb, valgind , profilers), IDE (Kdevelop, VisualStudio), которые позволяют легко находить синтатические ошибки, оптимизировать код и "упрощает процесс отладки".

Вы пропустили маленькое примечание что код чужой, уже откомпилированный, с различными оптимизациями и прострипан для уменьшения веса. :)

>> А это сценарий 90% веб приложений.

>думать надо "ширше", например, как это сделал в недавнем прошлом google.

Согласен, но использовать телескоп когда нужен микроскоп тоже не верно. Всему своя ниша. См. ваш ответ в пункте 5 - там оно к месту. И мой предыдущий ответ в пункет 6 - там оно не к месту. Просто насколько я понимаю автора топика - ему не надо с железяками работать, его задача входит в те 90%.

2. >> озволяет подключать через врапперы любые либы.

>я говорю о том, что в моем случае, это может делать "с пол-пинка" любой пользователь, с любой lib, а не ждать, когда выйдет новая версия PHP, с новыми PHP extensions. Не надо ждать, надо писать свой екстеншен. Не знаю честно как с этим в пхп, а в перле - с полпинка.

3. >> database logic на с++ - это жесть :)

>database logic на JDBC - это не тоже самое? даже Oracle имеет свою C++ wrapper lib.

Понимаете - все ресурсоемкие операции должна делать БД. Если это не так - вы плохо спроэктировали базу. А оставшаяся часть должны быть легко читаема и изменяема. И тут рулят различные скриптовые языки.

4. >>Вынужден вас огорчить

>не надо меня огорчать, я знаю php, mod_perl, etc. "изнутри", как apache modules developer.

а это тут при чем?)

5. >> но нужен ли он автору топика?

>про автора топика не знаю, но уверен, что таких желающих найдется много (я один из них). Сейчас "оживляю" одну железяку (http://www.kip.uni-heidelberg.de/ti/DCS-Board/current/) на ней стоит "boa webserver". Я с удовольствием хотел бы иметь к ней active GUI web interface.

Даже нокиа для желающих "поразмятся" подняла питон в симбиане, а вы все в С/С++ уперлись :) Хотя не отрицаю, что это возможно для вас и оправданно.

6. >>кажем простенькую страничку ...

>несомненно, главным приемуществом PHP является наличие огромного колличество написанного софта, всяческих заготовок и пр. Одна из моих идей написать php2c translator используя тот же самый Zend-engine (ведь именно это он и делает, в конце концов).

...огромного кол-ва криво написанного софта, если быть точнее :) Нет, не совсем это он делает. Или даже совсем не это.

>А вообще-то, спасибо :)

Да незачто, пишите :)

>Еще раз хочу поблагодарить за обсуждение - с интересом читаю, но молчу, т.к. полное ничтожество в вопросах программирования под WEB.

Всегда пожалуста, на лоре потрындеть все горазды :)

>Если я верно Вас понял - то осноаные тезисы, вытекающие из обсуждения:

>1. Более-менее распространенные вещи лучше делать на PHP - под них есть куча готовых наработок.

>2. Что-нибудь оригинальное - можно писать на том, что лучше знаешь.

В принципе - да. Брать готовый велосипед когда он есть, и делать свой если его нет.

>В моем случае нужно взяться за серверную часть онлайновой игрушки. Как в таком случае будет звучать ответ на вопрос C ws. PHP?

Понятие онлайн игрушки очень большое. Если это нечто типа бойцовского клуба и ему подобных - то пхп будет вполне достаточно. Т.к. нет никаких высокоемких вычислений.

>И еще вопрос. Хостинг на OnSmart.net (если это важно) - работает ли он со скриптам(или если оно написано на С - уже называется не скрипт?), написанными на С? Насколько часто у хостеров есть поддержка таких скриптов? Это обычно включено по умолчанию или с ними нужно "списываться" и просить активировать?

Если вы будете писать на С то в результате наверное будете получать просто двоичный исполняемый файл. Запускатся он будет как обычное CGI приложение(обычный запуск приложения как с командной строки, в переменных окружения переданны параметры такие как УРЛ по которому вас вызвали, IP вызывающего хоста, ГЕТ параметры - те что в строке браузера идут и т.д. А из STDIN вы вычитываете ПОСТ параметры все. После чего выдаете на STDOUT готовый хтмл. После чего программа завершается). Смотрите просто поддержку cgi. Но, лучше будет если найдете хостера с fast-cgi и напишите с поддержкой этой технологии(это почти тоже самое, только программа запускается один раз и висит в памяти ожидая пинка при каждом запросе, при пинке выполняет те же действия).

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

стало походить на флэйм :)

1.
>Вы пропустили маленькое примечание что код чужой, уже >откомпилированный, с различными оптимизациями и прострипан для >уменьшения веса. :)

не понял.
То о чем я говорю - у меня есть собственный скрипт,
для того чтобы он работал без ошибок (те же синтаксические),
я использую все перечисленные выше средства.
btw, эта техника позволяет иметь скрипты до 10000 строк,
что в PHP просто не возможно.

3.
>все ресурсоемкие операции должна делать БД
согласен.

не совсем в тему:
большинство web DB - так называемые read only DB,
когда данные только добавляются и селектированно считываются,
поэтому, IMHO, все эти MySQLи - это не совсем то, что нужно
использовать.

>А оставшаяся часть должны быть легко читаема и изменяема
не совсем в тему:
когда мне говорят, что C++ сложный язык, я отвечаю - пишите на C,
который проще PHP.

btw,
кто знает как написана EVE?
http://www.eve-online.com/

1. Ну вот обьясните, почему вы упорно зовете программу на С скриптом? Это никак не скрипт!

Если скрипт занимает 10000 строк - то в попу такой скрипт конечно же. Как там - разделяй и властвуй? Скрипт должен быть не более пары сотен строчек.

>То о чем я говорю - у меня есть собственный скрипт,

Если у вас есть собственная программа из 10к строчек - значит вы потратили на это не менее года. А если вы используете стороние модули - то они уже могут быть откомпилированы. И исходников может не быть.

3. >MHO, все эти MySQLи - это не совсем то, что нужно использовать.

Оно стало таким популярным ДЛЯ ВЕБА именно потому что оно - то что нужно для пользователя. Оракл и др - давали слишком много, и кушали тоже много. Мне вообще понравилась SQLite.

>когда мне говорят, что C++ сложный язык, я отвечаю - пишите на C, который проще PHP.

ну тот же брейнфак еще проще, но читабельность кода?

>кто знает как написана EVE?

http://pc.gamezone.com/news/09_08_06_11_30AM.htm

не совсем то, но масштабы )

> Ну вот обьясните, почему вы упорно зовете программу на С скриптом

потому что я говорю о C/C++ interpreter
http://root.cern.ch/twiki/bin/view/ROOT/CINT
на котором основан мой apache module.

Я также являюсь разработчиком http://root.cern.ch

> Если у вас есть собственная программа из 10к строчек -
> значит вы потратили на это не менее года

во "флагманском" режиме 2-3 месяца.

Я говорю о том, что я видел рабочие скрипты более 5K LOC,
как результат совместной работы (хотя конечно это неправильно,
для того и нужен C++), кстати, написанные не профессинальными
програмистами, а физиками.

> потому что оно - то что нужно для пользователя

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

> понравилась SQLite

мне тоже, и знаком с ее создателями, Richard Hipp & Dan Kennedy

> большинство web DB - так называемые read only DB, когда данные только добавляются и селектированно считываются, поэтому, IMHO, все эти MySQLи - это не совсем то, что нужно использовать.

А по подробнее можно? что не устраивает, SQL-интерфейс или реализация?

MySQL нетранзакционный, как раз по большей части на чтение и рассчитан... PostgreSQL со своим vacuum'ом как раз ведет себя хорошо если вы никогда ничего не удаляете...

> http://pc.gamezone.com/news/09_08_06_11_30AM.htm

во! только что нашел совсем свежую
http://opensourcepbx.tmcnet.com/news/2007/07/25/2811246.htm

оказывается они там пользуют "Stackless Python"

> что не устраивает

не устраивает то что, как MySQL, так и Postgre создавались,
как бесплатная альтернатива Oracle, работающая на мелких машинах
(они и сейчас за это борятся), но никак не для weba.
как я говорил web DB должна в основном (95% operations)
накапливать данные, и по запросу, как можно быстрей
его обрабатывать и выдавать результат (btw, именно так работает LOR).
Никаких update, insert, transaction (конечно не так категорично :).
Она даже может быть не сетевая, а файловая.
Так вот ни MySQL, ни Postgre такие цели не ставят.

Хм... очень интересная разработка. Смущает несколько моментов:

> Generally execution time is not critical, but rapid development is

Т.е. эффективность против того же php может быть и отрицательной? Есть ли какие-нибудь тест\сравнения?

> CINT covers about 95% of ANSI C and 85% of C++.

> It rather is a portable script language environment which is close enough to the standard C++. Please use simple expression whenever possible to avoid problems.

Т.е. в любом более-менее серьёзном проекте натыкаешся на грабли. Понятно, конечно, что в WEB вряд ли необходимы все прелести C\C++, но это не может не удручать тех, кто основным инструментом много лет использует именно эти языки. Ведь у каждого уже есть куча готовых отлаженых и соптимизированных алгоритмов\решений, и почти все они зачастую используют нестандартные подходы.

> эффективность против того же php может быть и отрицательной? Есть ли
> какие-нибудь тест\сравнения?

прямых сравнений не было ... но сушествует небольшая "утилита" ACLiC,
которая позволяет любой скрипт со всеми его потрахами
превращать в бинарный код (DLL). Для пользователя это совершенно
прозрачно. Сравнение скорости выполнения бинарного кода против
интерпретируемого дает фактор 3-10 и выше.
Обычно, для быстрой разработки, и всего того, для чего предназначены
скриптовые языки используется интерпретируемый код.
В "production and time critical" задачах
используется его бинарный вариант.

> конечно, что в WEB вряд ли необходимы все прелести C\C++,

я сам не люблю "все прелести C++", которые называю boost-ятиной.
несомнено надо писать на упрощенном C++, как в Java

> большинство web DB - так называемые read only DB, когда данные только добавляются и селектированно считываются

"read only DB, когда данные добавляются" - это приводит в ступор :-)

> как я говорил web DB должна в основном (95% operations) накапливать данные, и по запросу, как можно быстрей его обрабатывать и выдавать результат (btw, именно так работает LOR).

95% операций в web dbms - это все таки select'ы, а не накопление данных. Или вы про всякий data mining по логам говорите (который на ЛОРе не делается? да???)

> Она даже может быть не сетевая, а файловая. Так вот ни MySQL, ни Postgre такие цели не ставят.

Чего-то я вообще мысль потерял. MySQL и PostgreSQL - не сетевые, они реляционные, PostgreSQL более, MySQL менее. От сетевых DBMS там нету ни грама - если MySQL с MyISAM брать то там вообще внутри базы связей между таблицами никаких нет. Все соединения в запросе, в adhoc-манере.

Хотите файлов - их есть у MySQL. MyISAM таблица - это всегда 2 файла, InnoDB - можно указать чтоб каждая таблица была в своем файле. Копирование этих файлов - официально поддерживаемая операция.

Если вас интересует append-only dbms, то MySQL в этом направлении пару шагов сделало - archive tables и csv tables. Туда вроде только INSERT можно делать, UPDATE/DELETE не работают (сам правда не пробовал).

> я сам не люблю "все прелести C++", которые называю boost-ятиной. несомнено надо писать на упрощенном C++, как в Java

Вы случайно не Objective C ищете?

>gods-little-toy

сетевая, файловая ...
сетевая - эта та в которой есть "CONNECT DB"
файловая - в которой этого нет

> Вы случайно не Objective C ищете?

нет.
я имел ввиду, что программирование на C++ должно быть "упрощенным" и
"строгим" без boost-ятины (http://www.boost.org) и навотротов.

>сетевая - эта та в которой есть "CONNECT DB" >файловая - в которой этого нет

Да ну, бросьте. Есть централизованная БД, есть три отдельных веб-сервера (в разных филиалах). Некоторые данные берутся из основной БД. И это вполне традиционная задача

Ну используй тот же bdb в качестве БД.

> сетевая - эта та в которой есть "CONNECT DB" файловая - в которой этого нет

при всем уважении, plss..., по-легче с custom-терминологией. сетевая субд (http://ru.wikipedia.org/wiki/Сетевая_СУБД) -- устоявшийся термин, обозначающий вполне конкретный вид БД.

> обьясняю приемущества перед PHP:

Ню-ню.

> 1. возможно самое главное, то что C/C++ скрипт может быть скомпилирован, что значительно упрощает процесс отладки.

В каком месте? Затрудняет - да, понятно почему (deploy сложнее), а не ускоряет нигде. Hint: для Perl/PHP/Python существуют отладчики.

> Более того, скомпилированный скрипт может быть выполнен в бинарном виде. За счет чего достигается на порядок большее быстродействие относительно PHP и других скриптовых языков.

Это только если у тебя нету RDBMS...

> 2. гараздо лучшая расширяемость. По идее любая DLL lib доступна.

Биндинги для всех распространенных либ есть ко всем интересным языкам программирования. Не говоря уже, что есть SWIG и прочие boost::python-ы.

> 3. сам C/C++ код может быть использован не только для web programming, но и в других местах (например, database logic) ... и наоборот.

Это да, это правда. Но, опять же, на питоне, скажем, писать хранимые процедуры для PostgreSQL тоже можно.

> 4. возможна отладка вне web servera.

Гм. /usr/bin/{php,perl,python} cgi-script прекрасно работали, когда я последний раз проверял.

> 5. возможна работа непосредственно с железом, системой, что интересно для встроенных систем.

Это да, это правда. Там, правда, интереснее, скорее, экономия памяти на (незапуске) тех самых /usr/bin/{php,perl,python}, которые жрут по паре метров памяти.

> 6. и т.д. - это только немногое, что приходит в голову.

Только половина - неправда.

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

fcgi.com