Реализация FastCGI на современном C++

Уже давно есть CppCMS, которая развивается и тоже поддерживает FastCGI.

Было бы неплохо сделать сравнение.

Вот добавят туда концепты с аксиомами

Если ты про аксиомы в самих концептах, то их зарубили еще в C++0x. А если про контракты, то приняли, но это мелочь и вряд ли ты про это.

И как? Быстро работает?

Все основные/популярные языки вполне себе мультипарадигменные. Только большинство не пробует срезать ногти молотком... А с С++ фанбоями такое поведение весьма типично.

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

Интересно было бы послушать про мультипарадигменность Java.

Сможешь показать хотя-бы один язык, который имел бы 1) хотя-бы равную(ладно равной, просто находился рядом) систему типов, 2) обладал бы настолько мощной семантикой и архитектурой, что имел бы хотя-бы равный(либо рядом) компилятор(ы). 3) обладал бы равными(либо рядов) возможностями. Допустим, части управляемости(т.е. предсказуемости написанного кода), производительности, мощности компилтайм возможностей. 4) обладал бы равным(либо рядом) туллингом.

И самое важное. Существовал бы пруф состоятельности языка. Т.е. на нём был написан хотя-бы один проект равный С/С++.

Про такие мелочи как «знаешь/можешь в С/С++ - можешь во всё». Всё в этом мире написано на С/С++. Весь системный уровень, весь прикладной уровень. Попросту всё.

И как? Быстро работает?

«быстром» там даже и не пахнет.

Уже давно есть CppCMS, которая развивается и тоже поддерживает FastCGI.

CppCMS - это комбайн. А тут чисто реализация FastCGI.

Можно узнать, в чём именно заключается это «С++», «современном», «C++17»?

Я там увидел std::chrono, std::optional, std::unique_ptr, std::string_view и т.п. Это все относится к современному C++.

Оно явно было сделано под маздайку, а именно «Unix-подобных» там появилось постфактум и то вся поддержка ограничивается wsl(или как там оно называется).

Бред какой-то. Нигде там не говорится про WSL ни слова.

Реализация FastCGI на современном C++

Это самая распространённая ошибка плохих программистов по моим наблюдениям - программируют то, что не надо программировать. Всем известные примеры, производящие такое же тягостное впечатление - ReactOS и Haiku. Но там хотя бы есть коллективы, участники которых общаются между собой и кажутся друг другу адекватными.

FastCGI устарел, а когда не был устаревшим, программирование CGI программ на C/C++ было ненужным. Впрочем, были уже забытые интерфейсы ISAPI, ASAPI, NSAPI для C/C++, аналогичные FastCGI в том смысле, что ускоряли работу по сравнению с CGI за счёт меньшего числа загрузки программы в память. Забыты ввиду ненадобности. Автор проекта не потрудился узнать, чем пользуются сейчас и изобрёл даже не велосипед, а каменное колесо к каменной телеге.

Ну, посмотрел я его программный пример. Примитивное Hello World, но в нём видно неодобряемое применение «спагетти-кода» - HTML смешан с операторами C++. Подобное смешение создаёт большое неудобство в разработке и поддержке программы, поэтому с ним уже лет 20 как успешно борются (ну, не совсем успешно, раз находятся юные таланты, желающие заниматься фигнёй) с помощью языков шаблонов и библиотек генерации HTML. Возможно, автор не знает о них. А надо бы.

Бред какой-то.

Есть сильное ощущение, что delightfish — это очередная инкарнация Царя. Так что бреда здесь может быть еще много.

FastCGI устарел

Кто это сказал? Посмотрите на те же NGINX или Apache. Они прекрасно проксируют FastCGI. В NGINX так вообще навороченный модуль для FastCGI. А уж в PHP мире FastCGI используется вообще очень часто.

Примитивное Hello World, но в нём видно неодобряемое применение «спагетти-кода» - HTML смешан с операторами C++.

Для демонстрации почему бы и нет? А так, кто мешает взять какой-нибудь Mustache или ещё какой-нибудь шаблонизатор и писать приложение, отделяя код на C++ от HTML или JSON?

А уж в PHP

В действительности php - единственная причина почему до сих пор в апаче и nginx есть fastcgi.

Я там увидел std::chrono, std::optional, std::unique_ptr, std::string_view и т.п. Это все относится к современному C++.

Нет. Это просто «я узнал в интернете пару трюков». К С++ относится идиоматичный С++, к современному С++ относится идиоматичный С++ и «современный». Ничего из первого и второго там нет. Там даже хо прикручено сбоку, а это один из основных критериев(современности).

Бред какой-то.

В чём бред?

Нигде там не говорится про WSL ни слова.

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

Т.е. попроще. У тебя было posix-api и ты пытаешься портировать его под маздайку. У тебя прежде всего будет posix, то что в маздайке похоже на posix будет posix. Всё остальное - как получится. Здесь же явно видно, что базовой имплементацией является маздайка.

Третье, любой posix имеет два компилятора. Это clang/gcc. Все о них знают и все их поддерживают. Нельзя жить в мире unix и не знать о clang(как минимум потому, что есть всякие мир bsd/mac и прочее). К тому же, весомая часть туллинга имеет в основе clang. Т.е. ты не можешь разрабатывать на unix и под unix и не использовать clang.

Значит - ты разрабатываешь код под маздайкой. В маздаской ide. Это очевидно.

Почему я сказал про wsl. Всё просто. Потому что там gcc. Потому что, даже если у тебя дуалбут - про clang ты всё равно узнаешь.

А вот если ты просто пускал что-то в бубунте wsl, то ясно почему там 7.3 и почему именно gcc.

К С++ относится идиоматичный С++, к современному С++ относится идиоматичный С++ и «современный». Ничего из первого и второго там нет.

Ну и в чём там «неидиоматичность»?

Почему я сказал про wsl. Всё просто. Потому что там gcc. Потому что, даже если у тебя дуалбут - про clang ты всё равно узнаешь.

Это ничего не доказывает. Всего лишь домыслы и предположение, логические рассуждения, но не более того. Но даже если и так, то что это меняет? Попробуйте собрать этот код на настоящем линуксе и/или с помощью clang. Заодно и нам расскажите.

Значит - ты разрабатываешь код под маздайкой. В маздаской ide. Это очевидно.

Но если даже и так, то что это меняет?

В действительности php - единственная причина почему до сих пор в апаче и nginx есть fastcgi.

То есть пока жив PHP будет жить и FastCGI. А PHP будет жить ещё очень долго. Может быть даже дольше, чем C++. Кто его знает?..

Есть сильное ощущение, что delightfish — это очередная инкарнация Царя. Так что бреда здесь может быть еще много.

Вот интересно, зачем ему все это надо?

Какое доказательство? Какие аргументы?

Мысль такова:
1. Just for fun - достаточное оправдание для того, чтобы что-то сделать.
2. Иногда из just-for-fun, то есть из сделанного без какой-то очевидной пользы, вырастает что-то действительно стоящее. Слово «иногда» - ключевое.

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

https://en.cppreference.com/w/cpp/keyword/axiom а это что тогда?

Давно занимаюсь всяким C++ под веб, но обычно в режиме вкомпилить всё в один бинарник, который слушает порт» без всяких там HTTP-серваков на фронте, а с собственным разбором HTTP. Если есть такие же наркоманы, можно закорешиться. Люблю поупарываться ради иллюзорного профита и считаю кресты хорошим языком для веба, удобным и няшным.

Соглашусь!

Кстати, сейчас, как ни странно, плюсы в облаках взлетают. Там же люди глубоко упарываются оптимизацией использования ресурсов и автоскэйлингом. А на нодах, да питонах нормальный многопоточный epoll()-based REST-сервак или проксю не запилишь дабы все головы заюзать без накладных расходов на IPC (как в случае использования решений для питона/ноды, когда многопоточность многопроцессностью пытаются заменить).

А так - берешь HTTP-парсер от nodejs, сращиваешь это с boost::asio и всё это дело реально очень даже просто реализуется на плюсах! Только не забываем о TDD...

P.S. Была шизовая мысль запилить на плюсах сервак, который для каждого клиентского соединения создаёт полноценный независимый nodejs execution environment и через общий для всех epoll() выполняет серверные JS-скрипты - этакий многопоточный nodejs...

А так - берешь HTTP-парсер от nodejs, сращиваешь это с boost::asio и всё это дело реально очень даже просто реализуется на плюсах!

Уже есть такое. Называется RESTinio - https://github.com/Stiffstream/restinio

Уже есть такое. Называется RESTinio - https://github.com/Stiffstream/restinio

И я бы не сказал, что это просто ;)

Вот интересно, зачем ему все это надо?

Думаю, что нет смысла искать логику в поступках больного (в медицинском смысле) человека.

Ну и в чём там «неидиоматичность»?

  const char* const crlf = "\n";
  const char* const crlfcrlf = "\n\n";

std::string_view

На этом можно закончить.

Это ничего не доказывает.

Доказывает. Всё.

Всего лишь домыслы и предположение, логические рассуждения, но не более того.

У тебя нет альтернативного мнения и его обоснования. Если нету - я прав по определению. Когда существует лишь одна гипотеза - она является наиболее правильной, к тому же это даже далеко не гипотеза.

Но даже если и так, то что это меняет?

Это так. Шанс моей ошибки крайне мал. Ты - автор(либо рядом), и ты знаешь, что я прав.

Меняет много чего. Как минимум автор врёт. Зачем он врёт, зачем пытается обмануть меня/других людей? Я не любою когда меня считают за идиота и врут.

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

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

Попробуйте собрать этот код на настоящем линуксе и/или с помощью clang. Заодно и нам расскажите.

Зачем?

Но если даже и так, то что это меняет?

Ну шансы на этой крайне велики. Что меняет - обман, я уже писал о следствиях.

Ты мало того, что приписал себе те достижения, которых нет. Ты лишил себя возможности развиваться, способствуешь лишению других. Это плохо. Даже если тебе на себя насрать - не насри на других. Ради С++, ради комьюнити, ради справедливости.

Дежавю, однако. Не так давно это уже было на хабре и уже было хорошенько обосрано.

Ну вот пример реализации HTTP-прокси (игрался в свободное время): https://pastebin.com/shV4sz07. Всего 370 строк с логгингом всяким, а чистого кода - пара-тройка экранов. Эта штука легко масштабируется на любое кол-во потоков (спасибо дизайнерам boost::asio), посему нагрузку распределит по всем головам и даст тебе полную свободу. Неужели оно сложно выглядит?

а это что тогда?

Контракты, я же про них написал. Твое «концепты с аксиомами» парсится неоднозначно.

Как курсовая или proof-of-concept сойдет. Но пускать такое в продакшен... Так себе идея.

На этом можно закончить.

Т.е. использование строковых литералов в коде - это уже deprecated и все должны писать std::string_view, если не пишут, то код - отстой? Ну да, сильно. Да и где там const char* const crlf = «\n»; ?

Доказывает. Всё.

Все яснопонятно. Дальше читать нет смысла.

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

Т.е. использование строковых литералов в коде - это уже deprecated и все должны писать std::string_view, если не пишут, то код - отстой? Ну да, сильно. Да и где там const char* const crlf = «\n»; ?

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

Все яснопонятно. Дальше читать нет смысла.

Дальше тебе попросту ответь нечего.

Как видим, реализация относительно проста

Она проста именно потому, что PoC. Стоит начать работать над гибкостью и надежностью, расширением функциональности, так вся простота куда-то улетучивается.

посему ведущие игроки давно делают что-то подобное сами.

Под «ведущими игроками» кто подразумевается?

https://github.com/dmitigr/fcgi/commit/289e08d15a4ced385a04c803eff600537f4444... - смотри как ты несогласен со мною, ты в комментах строил из себя невесть что, косплея непричастных людей(что и сейчас пытаешься делать), а сам пошел править.

https://github.com/dmitigr/fcgi/commit/289e08d15a4ced385a04c803eff600537f4444...

И что тут такого? Замена ifdef на манипуляторы потока. Правильные улучшения. Или ты возражаешь?

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

Экстрасенс из тебя никакой.

Стоит начать работать над гибкостью и надежностью, расширением функциональности, так вся простота куда-то улетучивается.

Тут как обычно - как делать, так и будет.

Под «ведущими игроками» кто подразумевается?

Тут тоже как обычно: Гугль, Яндекс, etc. :)

Тут как обычно - как делать, так и будет.

В этом и был поинт: если делать хорошо, то это не будет просто. И сделать хорошо, обычно, не быстро.

Тут тоже как обычно: Гугль, Яндекс, etc. :)

Лисапеды, подобные обсуждаемому в данной теме, нужны в первую очередь не Гуглю с Яндексом.

И что тут такого? Замена ifdef на манипуляторы потока. Правильные улучшения. Или ты возражаешь?

Пытаешься заниматься клоунадой? ifdef здесь не причём. Ты убрал не его, а char *.

Экстрасенс из тебя никакой.

Экстрасенс из меня отличный.

Когда в php появится стандартный удобный http-сервер - fastcgi умрет совсем.

Что за дичь ты несшь, каким ты вобще боком смог сравнить раст с луа и пхп? У них общего чуть меньше, чем ничего.

У них общего чуть меньше, чем ничего.

Почему? Я думал, да и наблюдаемая мною картина мира, говорит об их похожести.

Наблюдал я её тут: https://habr.com/ru/post/450512/ Да и много где ещё. Факты говорят о том, что раст явно не из мира С/С++. А так же говорят о том, что он где-то рядом с luajit и пхп.

Ну вот, царя накликали.

И что там, запуск нативного кода из luajit (ffi)? И каким это боком делает Rust похожим на Lua? Каждый первый язык имеет способ дёрнуть нативный код, но это не делает ни один из них похожим на другой.

Неси сходства списком.

И что там, запуск нативного кода из luajit (ffi)?

И что там, запуска нативного кода из rust(ffi)?

И каким это боком делает Rust похожим на Lua?

Обыкновенный. Такое же ffi, такая же производительность.

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

Правильно, каждый из этих «языков» дёргает нативный код. Объединяет их то, что без ffi и нативного кода - их попросту не существует.

Если есть нативный язык, то он не может слить «вызову нативного языка». В это так же отличие.

Насколько я знаю, С++ обладает самой мощной системой типов в мире.

В плюсы завезли типы высшего порядка? Кон- и контр- вариативность типов?

Линейные и зависимые типы?

Гомотопические типы?

А вот тут и разница подъехала: Rust сам компилируется в нативный код, который может как дёргать, так и быть дёрнутым. Это и делает его похожим на C/C++.

Rust сам компилируется в нативный код

Нет.

который может как дёргать, так и быть дёрнутым.

Дёргать может любой пхп. А дёргать пхп нет смысла. Он сливает нативному коду.

Это и делает его похожим на C/C++.

Не делает. С/С++ дёргают не потому что они дёргают. А потому что их есть смысл дёргать. А остальное не дёргают не потому, что нельзя, а потому что нет смысла. Дёргать можно. Ту же juajit/js/пхп - что угодно.

В плюсы завезли типы высшего порядка?

Что это за базворды? Насколько я помню - это что-то из детского садика? Ну нет, С++ таким не занимается. Я не знаю базвордов из детского садика, говори что-то известное серьёзным пацанам.

Кон- и контр- вариативность типов?
Линейные и зависимые типы?
Гомотопические типы?

Это всё тоже оттуда. Я слышал, что детки в садике любят придумывать всякие новые слова. Жалко только, что эти слова существуют только в бурных обсуждениях времён сончаса.

Пытаешься заниматься клоунадой? ifdef здесь не причём. Ты убрал не его, а char *.

Опять бред. Там же черным по белому сказано: реализован манипулятор для ostream. Посмотрите как реализован этот манипулятор - o.write(«\r\n», 2). Никуда он не убрал char *, а просто завернул его в манипулятор (и правильно сделал).

Экстрасенс из меня отличный.

Ога, как же.

Опять бред. Там же черным по белому сказано: реализован манипулятор для ostream. Посмотрите как реализован этот манипулятор - o.write(«\r\n», 2). Никуда он не убрал char *, а просто завернул его в манипулятор (и правильно сделал).

Врёшь. У тебя там изначально это было. ТЫ использовал строковые литералы. Потом ты решил вынести их. Потом я тебе об этом сообщил. И ты опять вернул литералы. Не пытайся меня обмануть.