Комментарии 38
Проект был… эмм… не очень надежным и постоянно падал. :)
Разве что докера тогда не было.
Вот даже не поленюсь разобраться с главным:
С++ невероятно быстр в работе с хорошим кодом. Интерфейс CGI немного замедляет работу, но даже так вы получите выполнение лучше, чем на интерпретируемых языках вроде PHP.
Быстр — это прекрасно. Вот только скорость вычислений в вебе не очень-то важна. CGI-программы не занимается тяжелыми вычислениями. А сэкономленные сто тактов процессорного времени просто потеряются на фоне ожиданий и задержек, вносимых запросами к базе данных и операциями ввода-вывода.
А вот про что автор скромно умолчал:
- Страницы приходится формировать вручную чуть ли не построчно. Т.е. ни о каком редизайне сайта речи быть не может: поди разберись в тысячах строчек, где выводятся куски страниц. Если же грузить страницы из внешних файлов, то получится свой самописный шаблонизатор — т.е. тот же PHP, но обрезанный и свой.
- То, что текст всех страниц хранится в памяти, приводит к разрастанию бинаря. Чем больше разнообразных страниц отдает сайт в своих ответах, тем больше текста в бинаре. При этом на любой запрос в память грузится весь бинарь, хотя в ответе реально используется лишь малая часть текста. Тут можно возразить, что текста будет меньше при правильном разбиении страницы на хедер, футер и прочие стандартные части. Это так, но для больших проектов текста будет все равно очень много. Можно, конечно, собрать несколько разных бинарей… :)
- Если бинарь упадет по ошибке, то найти причину падения будет очень сложно. Особенно если нет core dump'а. Или нет отладочной информации.
- Если на сайт большая нагрузка, обновить бинарь не удастся. Пока программа работает, исполняемый файл блокируется от записи (не всегда, не везде, но бывает). Придется приостанавливать веб-сервер или химичить с символическими ссылками.
Это то, что сходу вспомнилось.
А, и еще один веселый момент: если сайт расположен на хостинге, то тамошний админ может сильно удивиться, обнаружив у клиента непонятный бинарь с правами запуска. Ну и удалит его нафиг для ясности. :)
Правда, таким макаром и до собственного интерпритатора недалеко…
Из плюсов использования 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. Предложите тогда решение...
Ответ понятен.
Но современный c++ ничем не хуже. И годится для самых разных задач. И для веба тоже.
Сейчас-то да, хотя время уже давно упущено.
Речь шла о С++ 15-летней давности. Ну и плюс к тому — гражданин писал на нем как на слегка улучшенном си — ASCIIZ строки, strcat/strlen, вот это все.
формировать страницы на с++ можно так же, как и на других языках, хранить текст можно в любом количестве файлов, отладочную информацию и корки иметь никто не запрещает, блокировка по записи ни на что не влияет, т.к. файл не перезаписывается при обновлении, а создается новый и переименовывается вместо старого. хотя с последним пунктом может быть сложнее несчастным пользователям виндовых вебсерверов, но опять же дело не в с++
А где-то сейчас живёт форум на ассемблере, на хабре о нём статья есть: https://m.habr.com/ru/post/318916/ ...
Например, вы глубокий параноик и считаете, что весь более-менее сложный софт уязвим.
Поэтому какие-то злобные хакеры перидоческих находят зиродеи в этих ваших апачах, энджинксах, и пехапе.
И сразу же идут атаковать ваш сайт.
Поэтому вы пишете свой веб-сервер, у которого будет свой аутентичный набор уязвимостей, которые никому не известных.
Но это до первого попадания бинаря в лапы варага.
И да, HTTP запрос надо ручками парсить, а то вдруг что…
Бесполезная фигня.
Хочешь сайт на C++ — напиши простейший сервер на C++ и интегрируй в него контент. Будет работать в разы быстрее.
Для вывода служебной статистики и диагностики вполне удобно.
Уже такую пятую или шестую статью на Хабре вижу. Без комментариев, насколько это полезно (уже сверху много на эту тему написали), но каждый раз удивляюсь — почему авторы сих статей отказываются рассказывать про что-то, по крайней мере, упрощающее разработку и развивающееся? Тот же https://www.webtoolkit.eu/wt, к примеру. Опять-таки, не утверждаю, что это нужно, но хотя бы на что-то эти проекты годны, в отличие от предлагаемого всеми этими авторами.
Пример хорошего использования — к примеру, делаем железку силами команда С++- программистов, нужна на ней веб-морда с настройками/результатами работы. Можно отдать на аутсорс, а можно что-то подобное попользовать.
Можно же и просто веб-проект делать на С++, без железки.
Или вот такой микро-фреймворк имеется: pistache.io
15 лет назад видел сайт на Delphi 6. Тот же метод реализации. Можно подобное сделать на assembler, но вопрос зачем? На Ruby или Python это можно сделать в десятки раз быстрее и проще. Если требуется большая производительность то Golang. Web решение на golang возможно будет даже быстрее чем на C++. Не нужно стрелять из пушки по воробьям, нужно выбирать инструмент адекватный требованиям. Автору, спасибо за статью. Было очень интересно.
Из примеров Web приложений на Си это форум МФТИ, который написан на Си, работает уже ~20 лет — board.rt.mipt.cc. Насколько помню, до этого была такая же борда, написанная на каком-то скриптовом языке и она тормозила, поэтому переписали на Си. Исходный код есть на Гитхабе.
Без питонов/PHP/апача — чисто под thttpd подложить (причем в голом chroot'е) и всё.
PS. А проверка на наличие POST не нужна, что ли?
То что CGI скрипты нагружают больше сервера – это так. Но когда скрипт написан на компилируемым языком как C++, C или ассемблер и инициализация этого скрипта быстрая, то нагрузка не так уж и большая.
А если нельзя запускать быстро из за инициализации, то всегда можно перейти на FastCGI или SCGI.
И веб на C++ совсем не такая экзотика. Например Fossil именно так и делает весь веб интерфейс. Эта ссылка ведет именно на сайт на C++.
То есть, общий вывод из этого такой.
Сервить странички на C++ в 2019 году нужно только разве что, если у вас там глубокий embedded и вы занимаетеь байтоеб… ом.
Играюсь с uWebsocketsjs C/C++ аддоном для ноды (можно использовать без ноды uWebsockets). Очень шустрый http сервер (https не тестировал).
Сравнивал поверхностно с отдачей строки из nginx и нода с аддоном плевалась ответами незначительно лучше. Тесты были на nginx 'из коробки' и не претендуют на абсолютную истину, но настраивать nginx не было никакого желания.
Велосипедить тоже интересно, но я инвалид без нормальных знаний C/C++, чтобы писать что-то быстрое на нём. Хотя перенести в C++ кэш с мелкой статикой было бы неплохо (JS ArrayBuffer`ы должны, в моём понимании, передавать указатели в аддон, но я в исходниках ноды по этому поводу не копался).
Создание сайта с помощью C++