Comments 35
После знакомства с Slim и Mojolicious наследоваться от handler, как то не хочется. Поэтому silicon выглядит чуточку приятней.
Если речь идет о Web-UI или Web-API для существующего C++ приложения — да, может оказаться удобно.
Но не в данном случае, т. к. требует стороннего веб сервера. Для таких случаев подходит что-то со встроенным веб сервером CppCMS, Wt и т.д.
UI — очень размытое понятие. Например под os/400 с точки зрения разработчика ui пользователь представляется как файл, в который можно писать и с которого можно читать (ессно можно при этом использовать select например) :)
Была задача: оценить возможность создания web интерфеса для существующего приложения. Т.е. "функционал" уже есть, и он был написан на C++ задолго до этого.
Переписывание всего приложения на Ruby, nodejs или др. только из-за удобства создания web приложения не имеет смысла, так как приложение должно и дальше быть доступным на платформах Windows, Mac OS X и Linux.
Я допускаю, что fastcgi не лучший вариант для этого, однако считаю что в любом случае лучше использовать C++ для интеграции C++ приложения в web.
Переписывание всего приложения на Ruby, nodejs или др. только из-за удобства создания web приложения не имеет смысла, так как приложение должно и дальше быть доступным на платформах Windows, Mac OS X и Linux.
Я допускаю, что fastcgi не лучший вариант для этого, однако считаю что в любом случае лучше использовать C++ для интеграции C++ приложения в web.
> однако считаю что в любом случае лучше использовать C++ для интеграции C++ приложения в web.
но как же так — если мы поверх накручиваем http сервер, JSP и xml — то это типа быстрее и проще и лучше
чем просто слать бинарный поток данных через сокеты?
но как же так — если мы поверх накручиваем http сервер, JSP и xml — то это типа быстрее и проще и лучше
чем просто слать бинарный поток данных через сокеты?
Нам недостаточно просто слать данные через сокеты. Нужны как минимум роутинг для доступа к разным частям API и поддержка параллельных запросов с тред-пулом. А это уже и есть сервер «накрученный поверх». Мы не стали изобретать свой, а взяли готовый Fastcgi Daemon и немного доработали его под свои нужды. Поддержка XML конфигов взята из него полностью. Транслятор шаблонов страниц в C++ код взят из POCO с небольшими доработками. В результате мы получили 100% интеграцию с нашими приложениями, упростив сопровождение.
Тоже самое можно было бы сделать, взяв за основу какой-либо готовый легковесный HTTP сервер (опять же на C++ для лучшей интеграции). Поэтому я и сказал, что допускаю, что fastcgi не лучший вариант для этого.
Тоже самое можно было бы сделать, взяв за основу какой-либо готовый легковесный HTTP сервер (опять же на C++ для лучшей интеграции). Поэтому я и сказал, что допускаю, что fastcgi не лучший вариант для этого.
На чем основано предположение, что ответ на C++ будет выдан быстрее? Сам по себе C++ позволяет конечно добиться многого, но чтобы это было действительно так, нужен довольно порядочный опыт. Да и не думается мне, что все возьмутся сами писать серваки с мультиплексированием запросов, с неблокируемым вводом-выводом, да при этом еще и асинхронные.
На boost.asio можно особо не напрягаясь написать асинхронный неблокирующий сервер.
Можно. А можно написать так, что он будет внезапно "дедлочится" (видел раз шикарный длинный while (true) со sleep(1) в обработчике). Всё делать с умом нужно. Асинхронность, даже с Asio, не особо простая штука.
Ну дык напишите. Если взять за основу их примеры, то очень долго потом будете искать фантомные баги, утечки и т.д. и это при условии, что они почти ничего не умеют. На деле пилить придется ну очень долго.
http://vibed.org/ в разы для этой задачи удобнее
Даже не верится, что этому поделию ровно 10 должно на днях исполниться :)
«Один пацан писал все на C++, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.»
В оригинале, если не ошибаюсь, про JavaScript было? Или сейчас всё с ног на голову перевернулось, и теперь уже за C++ на сервере в дурку забирают? :-)
Я уже ответил несколько раз лично Вам чем нас не устраивает JavaScript и почему мы используем C++.
«Holy war C++ vs. JS» устраивать не собираюсь, поэтому приводить иных аргументов не буду.
«Holy war C++ vs. JS» устраивать не собираюсь, поэтому приводить иных аргументов не буду.
Ответы на 1 и 3 лично вам:
habrahabr.ru/post/280814/#comment_8838182
habrahabr.ru/post/280814/#comment_8838298
habrahabr.ru/post/280814/#comment_8840166
2: Я и не утверждал, что вы к чему-либо призываете. Я несколько раз ответил вам лично почему мы используем C++. И всё… ;-)
habrahabr.ru/post/280814/#comment_8838182
habrahabr.ru/post/280814/#comment_8838298
habrahabr.ru/post/280814/#comment_8840166
2: Я и не утверждал, что вы к чему-либо призываете. Я несколько раз ответил вам лично почему мы используем C++. И всё… ;-)
Тогда в их случае придется делать взаимодействие их приложения с сервером на котором крутится JS. Что вы предлагаете использовать для взаимодействия?
шаблоны JSP, серлеты, xml зачем копировать java серверный стек если можно просто использовать java серверный стек. с java хоть глобально и надежно будет.
если б оно еще например из JSP и xml собирало С++ код. это веть идеология С++ вычислять все насколько возможно во время компиляции а не исполнения приложения.
выглядит как студенческая поделка, не осилевшего java и которому засрали голову что С++ это гарантированно быстро и высокопроизводительно.
а как пишутся настоящие высокопроизводительные сервера на с++ можно посмотреть
https://github.com/xaxaxa/workspace/
http://xa.us.to/cppsp/index.cppsp
https://github.com/stefanocasazza/ULib
http://www.techempower.com/benchmarks/
там такой адский C++ код в стиле C или вообще написано на С (nginx), а не новомодных стандартах С++ и ООП
если б оно еще например из JSP и xml собирало С++ код. это веть идеология С++ вычислять все насколько возможно во время компиляции а не исполнения приложения.
выглядит как студенческая поделка, не осилевшего java и которому засрали голову что С++ это гарантированно быстро и высокопроизводительно.
а как пишутся настоящие высокопроизводительные сервера на с++ можно посмотреть
https://github.com/xaxaxa/workspace/
http://xa.us.to/cppsp/index.cppsp
https://github.com/stefanocasazza/ULib
http://www.techempower.com/benchmarks/
там такой адский C++ код в стиле C или вообще написано на С (nginx), а не новомодных стандартах С++ и ООП
Для наших числодробильных задач C++ подходит лучше чем, например, JavaScript.
К тому же приложения давно уже есть (GUI и CLI).
К тому же приложения давно уже есть (GUI и CLI).
Я отвечал Вам, а Вы в том числе и о JS (node.js) упоминали (здесь).
К тому же, для наших числодробильных задач C++ подходит лучше чем Java.
К тому же, для наших числодробильных задач C++ подходит лучше чем Java.
С++ для числодробилки — это здравая мысль.
вопрос в том — нафига тут xml, JSP, http сервлеты — реализуем серверный стек java, когда можно было просто слать бинарные данные через сокет
> К тому же приложения давно уже есть (GUI и CLI).
ну вот надо дисклеймер класными буквами в начале статьи — что это типа подход исторически сложившийся не используйте это в новых проектах.
а то люди могут неправильно понять и подумать что это новая штука для высокопроизводительных серверов на C++
вопрос в том — нафига тут xml, JSP, http сервлеты — реализуем серверный стек java, когда можно было просто слать бинарные данные через сокет
> К тому же приложения давно уже есть (GUI и CLI).
ну вот надо дисклеймер класными буквами в начале статьи — что это типа подход исторически сложившийся не используйте это в новых проектах.
а то люди могут неправильно понять и подумать что это новая штука для высокопроизводительных серверов на C++
Из двух первых ссылок:
«Адский код» нам тоже не нужен.
All the code i've ever written since grade 11; also includes some forward-ported code from grades 8 and 9«выглядит как студенческая поделка» ;-)
«Адский код» нам тоже не нужен.
Sign up to leave a comment.
Фреймворк Fastcgi Container