Pull to refresh

Comments 38

С созданием hello world на плюсах для CGI игрался еще лет 15 назад. Но кроме этого больше и не смог придумать для чего бы реально полезного можно было бы это применить.
как полноправного сайта на C создавать конешно смысла большого нет, но вот как локальный «сайт» для связи браузера с локальным железом — вполне. и такие поделки есть.
Лет 15 назад я видел самый настоящий проект для веба на плюсах — с базой данных и страничками, выводимыми через cout <<
Проект был… эмм… не очень надежным и постоянно падал. :)
Лет 20 назад на С++ с друзьями писал форум. Работало замечательно.
А ещё на С++ можно написать PHP (или что угодно другое) и больше не страдать ерундой.
Удивительное дело. Когда-то давно я такой проект видел — только с очень большим трудом удалось уговорить его создателя перейти на какой-нибудь скриптовой язык, чтобы проект можно было реально развивать. В процессе уговоров я слышал практически все «аргументы» за С++ в вебе, которые автор приводит в статье. 15 лет прошло, а заблуждения все те же. :)
Разве что докера тогда не было.

Вот даже не поленюсь разобраться с главным:
С++ невероятно быстр в работе с хорошим кодом. Интерфейс CGI немного замедляет работу, но даже так вы получите выполнение лучше, чем на интерпретируемых языках вроде PHP.

Быстр — это прекрасно. Вот только скорость вычислений в вебе не очень-то важна. CGI-программы не занимается тяжелыми вычислениями. А сэкономленные сто тактов процессорного времени просто потеряются на фоне ожиданий и задержек, вносимых запросами к базе данных и операциями ввода-вывода.

А вот про что автор скромно умолчал:
  1. Страницы приходится формировать вручную чуть ли не построчно. Т.е. ни о каком редизайне сайта речи быть не может: поди разберись в тысячах строчек, где выводятся куски страниц. Если же грузить страницы из внешних файлов, то получится свой самописный шаблонизатор — т.е. тот же PHP, но обрезанный и свой.
  2. То, что текст всех страниц хранится в памяти, приводит к разрастанию бинаря. Чем больше разнообразных страниц отдает сайт в своих ответах, тем больше текста в бинаре. При этом на любой запрос в память грузится весь бинарь, хотя в ответе реально используется лишь малая часть текста. Тут можно возразить, что текста будет меньше при правильном разбиении страницы на хедер, футер и прочие стандартные части. Это так, но для больших проектов текста будет все равно очень много. Можно, конечно, собрать несколько разных бинарей… :)
  3. Если бинарь упадет по ошибке, то найти причину падения будет очень сложно. Особенно если нет core dump'а. Или нет отладочной информации.
  4. Если на сайт большая нагрузка, обновить бинарь не удастся. Пока программа работает, исполняемый файл блокируется от записи (не всегда, не везде, но бывает). Придется приостанавливать веб-сервер или химичить с символическими ссылками.


Это то, что сходу вспомнилось.
А, и еще один веселый момент: если сайт расположен на хостинге, то тамошний админ может сильно удивиться, обнаружив у клиента непонятный бинарь с правами запуска. Ну и удалит его нафиг для ясности. :)
Вопрос с формированием страниц решается созданием простейшего шаблонизатора…
Правда, таким макаром и до собственного интерпритатора недалеко…

Из плюсов использования C++ в вебе — Это возможность обойтись и вовсе без веб-сервера (написать свой, как часть сайта, либо воспользоваться uHttp или другим мини-сервером).
Ещё большим плюсом будет малый размер исполняемых файлов, что критично для всяких роутеров и прочим мини-девайсов.
Вопрос с формированием страниц решается созданием простейшего шаблонизатора…
Правда, таким макаром и до собственного интерпритатора недалеко…

Именно об этом я и говорю.

Из плюсов использования C++ в вебе — Это возможность обойтись и вовсе без веб-сервера (написать свой, как часть сайта, либо воспользоваться uHttp или другим мини-сервером).

Ну так-то да. Только автор статьи рассказывает именно про CGI (причем на хостингах). На хостинге за открытие порта в неположенном месте могут и по тыковке настучать. :)
Не убедительно. В любом языке страница формируется построчно или шаблонизатором. И хранить все страницы в памяти это странно. Пользуйтесь фреймворками.
И хранить все страницы в памяти это странно.

А вы примеры посмотрите в статье — там все фрагменты страницы хранятся как строки. Где хранятся? Естественно, в памяти.

Если пользоваться шаблонизатором, то какой смысл писать свой, если есть уже готовый и очень неплохой — PHP называется? :)

Пользуйтесь фреймворками.

Какими? Qt — чтоб сразу +7 мегабайт в память загрузилось? :)
Если пользоваться шаблонизатором, то какой смысл писать свой, если есть уже готовый и очень неплохой — PHP называется? :)

PHP, всёж, интерпритатор.
А речь про примитивный шаблонизатор: Передача браузеру клиента HTML кода из файла, «на лету» подменяя ключевые слова (токены?) на нужный код или текст, который тоже можно подгружать из другого файла.

Правда всё это актуально на какойнить STM32 или Arduino, а на более производительных чипах, как правило, можно запустить чтото более удобное для разработки (php, nodejs/javascript, lua и т.п.)

Хотя я бы реализовал чуть иначе: На CGI — только Json API, всё остальное (html, js, css, jpg/png/svg) отдавать самим веб-сервером и делать логику по максимуму через js (Как, собственно, и делают многие современные сайты, перенося таким образом почти все вычисления на клиента)
Есть мнение, что С++ живет не только с QT. Предложите тогда решение на PHP для web сервера с 2 мб жёсткой памяти. Современный php, кстати, предлагает фреймворки на десятки мб. Я не в коем случае не ругаю php, я люблю писать на нем даже системные скрипты. Но современный c++ ничем не хуже. И годится для самых разных задач. И для веба тоже.
Есть мнение, что С++ живет не только с QT. Предложите тогда решение...

Ответ понятен.

Но современный c++ ничем не хуже. И годится для самых разных задач. И для веба тоже.

Сейчас-то да, хотя время уже давно упущено.
Речь шла о С++ 15-летней давности. Ну и плюс к тому — гражданин писал на нем как на слегка улучшенном си — ASCIIZ строки, strcat/strlen, вот это все.
из ваших 4 пунктов ни один не описывает с++.
формировать страницы на с++ можно так же, как и на других языках, хранить текст можно в любом количестве файлов, отладочную информацию и корки иметь никто не запрещает, блокировка по записи ни на что не влияет, т.к. файл не перезаписывается при обновлении, а создается новый и переименовывается вместо старого. хотя с последним пунктом может быть сложнее несчастным пользователям виндовых вебсерверов, но опять же дело не в с++
Дело не в С++, а в том, что люди руководствуются при выборе языка странными представлениями. Ну а потом, понятно, мучаются.
Не ну смысл иногда есть.

Например, вы глубокий параноик и считаете, что весь более-менее сложный софт уязвим.
Поэтому какие-то злобные хакеры перидоческих находят зиродеи в этих ваших апачах, энджинксах, и пехапе.
И сразу же идут атаковать ваш сайт.
Поэтому вы пишете свой веб-сервер, у которого будет свой аутентичный набор уязвимостей, которые никому не известных.
Но это до первого попадания бинаря в лапы варага.
И да, HTTP запрос надо ручками парсить, а то вдруг что…
Знаете, никогда не страдал паранойей, исходил из принципа — да кому я нужен, меня взламывать. Сделал маленький простенький сайт для себя, причем вообще простой, без каких-либо движков и т.д. Смотрю логи по запросам: целая куча запросов в поисках файлов wordpress типа логина и еще других, потом поиски на разных уровнях каталогов файла /etc/passwd, а потом вообще пошли SQL инъекции. Я может еще не совсем параноик, но реально достали…
Это всё боты.
Я для них просто написал пару правил в Fail2ban.
Я тоже так думаю. Вот только не подскажите сылочку на какую-то статью про эти правила для Fail2ban как и куда писать?
Загуглите «Nginx + Fail2ban» (или «Apache + Fail2ban). И просто дополните их по аналогии (Там простой Regex).
А, понял. Спасибо! Попробую обязательно.

Бесполезная фигня.
Хочешь сайт на C++ — напиши простейший сервер на C++ и интегрируй в него контент. Будет работать в разы быстрее.

А что мешает прикрутить к программе на плюсах библиотеку во встроенным веб-сервером?
Для вывода служебной статистики и диагностики вполне удобно.

Уже такую пятую или шестую статью на Хабре вижу. Без комментариев, насколько это полезно (уже сверху много на эту тему написали), но каждый раз удивляюсь — почему авторы сих статей отказываются рассказывать про что-то, по крайней мере, упрощающее разработку и развивающееся? Тот же https://www.webtoolkit.eu/wt, к примеру. Опять-таки, не утверждаю, что это нужно, но хотя бы на что-то эти проекты годны, в отличие от предлагаемого всеми этими авторами.


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

Согласен, иногда очень нужная вещь)
Вот тоже вспомнил про github.com/emweb/wt
Можно же и просто веб-проект делать на С++, без железки.

Или вот такой микро-фреймворк имеется: pistache.io

15 лет назад видел сайт на Delphi 6. Тот же метод реализации. Можно подобное сделать на assembler, но вопрос зачем? На Ruby или Python это можно сделать в десятки раз быстрее и проще. Если требуется большая производительность то Golang. Web решение на golang возможно будет даже быстрее чем на C++. Не нужно стрелять из пушки по воробьям, нужно выбирать инструмент адекватный требованиям. Автору, спасибо за статью. Было очень интересно.

Лет 20 назад делал модуль на ISAPI для MS IIS, чтобы шустро с БД работать и видео-поток гнать. CGI — это недопустимо медленно. Под IIS и шаблонизаторы есть, странно что никто тут не вспоминает. MS AtlDriver/Server были, наверное фреймворк это сейчас называется, на выходе DLL была, которая в адресном пространстве IIS работала. Всё это шустро работало в одной торговой сети. Трудоёмко на С++ делать, JS проще.
если говорить о глобальном — то сайт на С мало отличается от сайта на java. jar/war или exe — по сути одно и тоже. что на С, что на java надо иметь исходники, что бы внести изменения. необходима трансляция. Только java кросплатформенное приложение, а С платформозависимое.
Согласен с другими комментаторами, такие статьи писали десять лет назад и ничего нового она не открывает. Для тех, кому интересно, есть два фреймворка для написания FastCGI приложений на Си: Kore и kcgi. Автор kcgi к тому же занимается евангелизмом стека BCHS (BSD, C, httpd, SQLite) — learnbchs.org, любопытные доклады и статьи.

Из примеров Web приложений на Си это форум МФТИ, который написан на Си, работает уже ~20 лет — board.rt.mipt.cc. Насколько помню, до этого была такая же борда, написанная на каком-то скриптовом языке и она тормозила, поэтому переписали на Си. Исходный код есть на Гитхабе.
Прекрасный вариант узкоспециализированного веб-сервера для «веб-хуков» — дернуть что-то там на сервере за какую-то ручку например.
Без питонов/PHP/апача — чисто под thttpd подложить (причем в голом chroot'е) и всё.

PS. А проверка на наличие POST не нужна, что ли?

То что CGI скрипты нагружают больше сервера – это так. Но когда скрипт написан на компилируемым языком как C++, C или ассемблер и инициализация этого скрипта быстрая, то нагрузка не так уж и большая.


А если нельзя запускать быстро из за инициализации, то всегда можно перейти на FastCGI или SCGI.


И веб на C++ совсем не такая экзотика. Например Fossil именно так и делает весь веб интерфейс. Эта ссылка ведет именно на сайт на C++.

Старт нового процесса на запрос — операция не дешёвая в любом случае.
Если нужно с полпинка поднять специализированный веб-сервер, то есть вполне современный вариант на Java и Netty.
То есть, общий вывод из этого такой.
Сервить странички на C++ в 2019 году нужно только разве что, если у вас там глубокий embedded и вы занимаетеь байтоеб… ом.

Играюсь с uWebsocketsjs C/C++ аддоном для ноды (можно использовать без ноды uWebsockets). Очень шустрый http сервер (https не тестировал).


Сравнивал поверхностно с отдачей строки из nginx и нода с аддоном плевалась ответами незначительно лучше. Тесты были на nginx 'из коробки' и не претендуют на абсолютную истину, но настраивать nginx не было никакого желания.


Велосипедить тоже интересно, но я инвалид без нормальных знаний C/C++, чтобы писать что-то быстрое на нём. Хотя перенести в C++ кэш с мелкой статикой было бы неплохо (JS ArrayBuffer`ы должны, в моём понимании, передавать указатели в аддон, но я в исходниках ноды по этому поводу не копался).

Sign up to leave a comment.

Articles