Всем привет.

Думаю, что это будет интересно, как ответ на принципиальный вопрос о применении C++ для Web-программирования. На сайте MicroNovae лежит движок C++ server pages. Ходить сюда: http://www.micronovae.com/default_csp.html

Кстати, разработка молодая. Как я понял, началась примерно в 2002-2003 г. Вероятно, не слишком большая популярность такого решения связана с такими причинами:

Первая — долгая стабилизация стандарта C++ и подтягиванием компиляторов.
Вторая — стереотип, который напрочь разделяет понятия "C++" и "Web-программирование".
Третья — приличная масса Web-программистов, у которых в послужном списке технологий есть SQL, Java, VB и нет C++.
Четвёртая — возможность создания потенциально опасного (exploiting) кода на C++. Согласитесь, что залезть в память средствами C++ не в пример проще, чем на Java.

Хотя четвёртая причина должна быть более актуальна для "публичных" провайдеров, которые рискнут предоставить CSP-хостинг. Для внутрикорпоративных же сайтов угроза exploiting-кода со стороны самих C++-Web-приложений существенно меньше, поскольку такой сайт может вовсе не содержать постороннего C++-кода. А скорость обработки запросов выше, однако. Сам я пока не проверял, но по идее, должно работать быстрее, чем JSP.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Всем привет.

ГВ>Думаю, что это будет интересно, как ответ на принципиальный вопрос о применении C++ для Web-программирования. На сайте MicroNovae лежит движок C++ server pages. Ходить сюда: http://www.micronovae.com/default_csp.html

ГВ>Кстати, разработка молодая. Как я понял, началась примерно в 2002-2003 г. Вероятно, не слишком большая популярность такого решения связана с такими причинами:

ГВ>Первая — долгая стабилизация стандарта C++ и подтягиванием компиляторов.
ГВ>Вторая — стереотип, который напрочь разделяет понятия "C++" и "Web-программирование".
ГВ>Третья — приличная масса Web-программистов, у которых в послужном списке технологий есть SQL, Java, VB и нет C++.
ГВ>Четвёртая — возможность создания потенциально опасного (exploiting) кода на C++. Согласитесь, что залезть в память средствами C++ не в пример проще, чем на Java.

ГВ>Хотя четвёртая причина должна быть более актуальна для "публичных" провайдеров, которые рискнут предоставить CSP-хостинг. Для внутрикорпоративных же сайтов угроза exploiting-кода со стороны самих C++-Web-приложений существенно меньше, поскольку такой сайт может вовсе не содержать постороннего C++-кода. А скорость обработки запросов выше, однако. Сам я пока не проверял, но по идее, должно работать быстрее, чем JSP.

ГВ>Вот так, или примерно так. Высказывайтесь, коллеги.

Не пощупав, трудно что-либо сказать.
Что касается популярности, то Web-дизайн -- слишком массовая профессия, что бы им заниматься на С++. Барьер квалификации, однако. Тут нужны более простые в освоении средства -- для чайников.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Шахтер, Вы писали:

Ш>Не пощупав, трудно что-либо сказать.
Я сейчас скачал, буду щупать. Глядишь, библиотечку какую-никакую сваяю. За ради унификации WinAPI-контролов и HTML-представления.

Ш>Что касается популярности, то Web-дизайн -- слишком массовая профессия, что бы им заниматься на С++. Барьер квалификации, однако. Тут нужны более простые в освоении средства -- для чайников.
Ладно, повременим с ёрничаньем. В "Философии програмирования" для этого всегда время и место есть.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хотя четвёртая причина должна быть более актуальна для "публичных" провайдеров, которые рискнут предоставить CSP-хостинг. Для внутрикорпоративных же сайтов угроза exploiting-кода со стороны самих C++-Web-приложений существенно меньше, поскольку такой сайт может вовсе не содержать постороннего C++-кода.

А со стороны корпоративных пользователей? Например, путем посылки хитрого запроса.

ГВ>А скорость обработки запросов выше, однако. Сам я пока не проверял, но по идее, должно работать быстрее, чем JSP.

На самом деле, интересно было бы посмотреть на более-менее реальное сравнение с ASP.NET/JSP. Некоторый набор стресс-тестов на более-менее реальном приложении. Мне, в общем-то, не особо понятно за счет чего CSP может сильно превзойти по скорости данные технологии.

Сравнение CSP с ASP у них на сайте — это, по-моему, издевательство какое-то. ASP же вроде интерпретируемый?

Здравствуйте, WFrag, Вы писали:

ГВ>>Хотя четвёртая причина должна быть более актуальна для "публичных" провайдеров, которые рискнут предоставить CSP-хостинг. Для внутрикорпоративных же сайтов угроза exploiting-кода со стороны самих C++-Web-приложений существенно меньше, поскольку такой сайт может вовсе не содержать постороннего C++-кода.
WF>А со стороны корпоративных пользователей? Например, путем посылки хитрого запроса.
Хм. Хакаются, вроде как, Web-серверы (т.е. — IIS, Apache и иже с ними), а не xSP-модули, которые сами по себе серверами не являются.

ГВ>>А скорость обработки запросов выше, однако. Сам я пока не проверял, но по идее, должно работать быстрее, чем JSP.
WF>На самом деле, интересно было бы посмотреть на более-менее реальное сравнение с ASP.NET/JSP. Некоторый набор стресс-тестов на более-менее реальном приложении. Мне, в общем-то, не особо понятно за счет чего CSP может сильно превзойти по скорости данные технологии.
Думаю, что в основном — за счёт более быстрой генерации Response-буфера.

WF>Сравнение CSP с ASP у них на сайте — это, по-моему, издевательство какое-то. ASP же вроде интерпретируемый?
Согласен, что тут они палку несколько перегнули, хотя смотрится впечатляюще. Особенно любопытно с JSP сравнить. Обязательно поковыряю на досуге.

Здравствуйте, Геннадий Васильев, Вы писали:

WF>>А со стороны корпоративных пользователей? Например, путем посылки хитрого запроса.
ГВ>Хм. Хакаются, вроде как, Web-серверы (т.е. — IIS, Apache и иже с ними), а не xSP-модули, которые сами по себе серверами не являются.

Хакается все. Если на обработке query string возможно переполнение буфера внутри С++-скрипта, то это самый обыкновенный эксплоит.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Всем привет.

ГВ>Думаю, что это будет интересно, как ответ на принципиальный вопрос о применении C++ для Web-программирования. На сайте MicroNovae лежит движок C++ server pages. Ходить сюда: http://www.micronovae.com/default_csp.html

ГВ>Кстати, разработка молодая. Как я понял, началась примерно в 2002-2003 г.

А я и раньше пользовался сями для Web-сервера, когда нужда была в закрытых исходниках и быстрой обработке большого количества запросов от клиентов)

Например, копай в сторону замечательного комплекса программ UCJ (используемые языки — C и Perl).

Здравствуйте, WFrag, Вы писали:

WF>Сравнение CSP с ASP у них на сайте — это, по-моему, издевательство какое-то. ASP же вроде интерпретируемый?

ASP страница это byte code который цепляется как stream к файлу с расширением asp.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот так, или примерно так. Высказывайтесь, коллеги.

"Секс это что новое или мы им всегда занимались?"

В смысле идея не нова. Года три назад то ли в DDJ то ли в CUJ была большая статья на тему.

По моему (не помню) в ней описывались C++ servlets
http://stud3.tuwien.ac.at/~e9626231/cse/home.html

На самом деле это есть ни что иное как ++тизация идей CGI и пр.
Что как известно работает и вельми.

Здравствуйте, c-smile, Вы писали:

CS>На самом деле это есть ни что иное как ++тизация идей CGI и пр.
CS>Что как известно работает и вельми.

А эта модель не работать попросту не может. Единственная относительно серьёзная проблема — время трансляции страницы в DLL. Всё же прочее — точь в точь JSP, ASP и прочее.

Здравствуйте, AndrewVK, Вы писали:

AVK>Хакается все. Если на обработке query string возможно переполнение буфера внутри С++-скрипта, то это самый обыкновенный эксплоит.

переполнением буфера обычно страдали программы на С, где все было на статических массивах или массивах фиксированой размерности.

если использовать STL, то максимум что произойдет — перевыделение памяти в недрах STL, эксплоит не возможен в принципе.

да и не скрипт там, а компиляция чего надо куда положено

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, c-smile, Вы писали:

CS>>На самом деле это есть ни что иное как ++тизация идей CGI и пр.
CS>>Что как известно работает и вельми.

ГВ>А эта модель не работать попросту не может. Единственная относительно серьёзная проблема — время трансляции страницы в DLL. Всё же прочее — точь в точь JSP, ASP и прочее.

время однократной трансляции

Геннадий Васильев -> "C++ server pages, однако"

ГВ> Первая — долгая стабилизация стандарта C++ и подтягиванием
ГВ> компиляторов.
ГВ> Вторая — стереотип, который напрочь разделяет понятия "C++" и
ГВ> "Web-программирование".
ГВ> Третья — приличная масса Web-программистов, у которых в послужном
ГВ> списке технологий есть SQL, Java, VB и нет C++.
ГВ> Четвёртая — возможность создания потенциально опасного (exploiting)
ГВ> кода на C++. Согласитесь, что залезть в память средствами C++ не в
ГВ> пример проще, чем на Java.

Пятая, которая косвенно проистекает из 2 и 3-й — время разработки приложения
(недостаточная квалификация, отсутствие бибилиотек и т.д.)

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

Здравствуйте, c-smile, Вы писали:

CS>ASP страница это byte code который цепляется как stream к файлу с расширением asp.

Сам-то понял что сказал?

Здравствуйте, vdimas, Вы писали:

V>переполнением буфера обычно страдали программы на С, где все было на статических массивах или массивах фиксированой размерности.

V>если использовать STL, то максимум что произойдет — перевыделение памяти в недрах STL, эксплоит не возможен в принципе.

Ага. Вот только почему то в сетевом софте, в том числе и писанном на плюсах, эксплойты находят регулярно.

V>да и не скрипт там, а компиляция чего надо куда положено

Скрипты тоже могут быть компилируемыми.

Здравствуйте, AndrewVK, Вы писали:

V>>если использовать STL, то максимум что произойдет — перевыделение памяти в недрах STL, эксплоит не возможен в принципе.

AVK>Ага. Вот только почему то в сетевом софте, в том числе и писанном на плюсах, эксплойты находят регулярно.

и что это за сетевой софт на плюсах, где есть эксплоит?

----------

но даже и на плюсах при достаточной кривизне рук ничто не мешает писать в духе С:

#define BIG_BUFF_LEN 1000

int some_func(stream* st) {
    ...
    char buff[BIG_BUFF_LEN]; 
    stream->read_string(buff);    // получи эксплоит
    ...
}

V>>да и не скрипт там, а компиляция чего надо куда положено

AVK>Скрипты тоже могут быть компилируемыми.

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

Здравствуйте, vdimas, Вы писали:

V>насколько мне казалось, скриптовые языки отличаются своей интерпретируемостью. причем некоторые скриптовые языки невозможно скомпилировать.
http://en.wikipedia.org/wiki/Script_language

Scripting programming languages (commonly called scripting languages or script languages) are computer programming languages designed for "scripting" the operation of a computer. Early script languages were often called batch languages or job control languages.

Contents
1 Description

2 Notes

3 List of scripting programming languages

4 External link

Description
Computer languages are created for varying purposes and tasks — different kinds and styles of programming. One common programming task is known as scripting, or connecting diverse pre-existing components to accomplish a new related task. Those languages which are suited to scripting are typically called scripting languages. Many languages for this purpose have common properties: they favor rapid development over efficiency of execution; they are often implemented with interpreters rather than compilers; and they are strong at communication with program components written in other languages

Разницу между often и always ощущаешь?

Вспомним историю развития средств:
1. CGI Хорошо, но медленно: для каждого клиента запускается отдельный процесс. Вместо этого придумали
2. ISAPI. Модули в DLL. Быстро, но глючно: AV в DLL приводит к обрушению всего web-сервера. Да и с обновлением версий модулей проблемы — требует перезапуска сервера
3. Скрипты: ASP, PHP и пр. Относительно быстро: всё в одном процессе. Надёжно: скрипт AV вызвать не может. Обновлять легко. Но когда код большой, насинаются проблемы: в коде не разобраться, да и работает не быстро, поэтому придумали 4:
4. Виртуальные машины: JSP, ASP.NET. Тут вроде пока всё хорошо. Надёжно. Довольно быстро. Код сложный можно писать. Обновлять легко.

Использование С++ в виде dll порождает проблему 2 — падение модуля приводит к падению сервера

Евгений Коробко -> "Re: C++ server pages, однако"

ЕК> Вспомним историю развития средств:
ЕК> 1. CGI Хорошо, но медленно: для каждого клиента запускается
ЕК> отдельный процесс. Вместо этого придумали
ЕК> 2. ISAPI. Модули в DLL. Быстро, но глючно: AV в DLL приводит к
ЕК> обрушению всего web-сервера. Да и с обновлением версий модулей
ЕК> проблемы — требует перезапуска сервера

2.1 Встраиваемые модули для apache (mod_perl, mod_php, mod_asp). Быстро и
безопасно.

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Использование С++ в виде dll порождает проблему 2 — падение модуля приводит к падению сервера
От кривизны рук всегда защититься сложно. Что поделаешь... Значит, просто требования к квалификации разработчиков должны быть выше.