Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Реализация FastCGI на современном C++"	+/–
Сообщение от opennews (??), 17-Май-19, 12:58
Доступна (https://github.com/dmitigr/fcgi) новая реализация протокола FastCGI (https://en.wikipedia.org/wiki/FastCGI), написанная на современном C++17. Библиотека примечательна  простотой в использовании и высокой производительностью. Возможно использование как статически и динамически  связанной библиотеки, так и  встраиванием в приложение в форме заголовочного файла. Кроме Unix-подобных систем обеспечена поддержка использования в Windows. Код поставляется под свободной лицензией zlib. URL: https://github.com/dmitigr/fcgi Новость: https://www.opennet.dev/opennews/art.shtml?num=50699
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Реализация FastCGI на современном C++"	+3 +/–
Сообщение от Аноним (1), 17-Май-19, 12:58
а чо, текущая реализация непростая и медленная?
Ответить | Правка | Наверх | Cообщить модератору

	3. "Реализация FastCGI на современном C++"	+13 +/–
	Сообщение от A.Stahl (ok), 17-Май-19, 13:00
	В тексте новости нет сравнения сложности и производительности, есть лишь утверждение что библиотека проста и производительна, поэтому твой вопрос не логичен.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Реализация FastCGI на современном C++"	+/–
	Сообщение от test_test (?), 17-Май-19, 15:40
	Как и сами утверждения в новости, не?
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Sw00p aka Jerom (?), 17-Май-19, 17:11
	и бенчмарков примитивных не вижу
	Ответить | Правка | Наверх | Cообщить модератору

	5. Скрыто модератором	–1 +/–
	Сообщение от Аноним (5), 17-Май-19, 13:07
	Зато эта для тех, кто крутит спинеры, деньги хранит в биткоинах, курит вейп, каждую неделю посещает барбершоп, пьёт исключительно смузи и по улице передвигается только на гироскутере. Короче не может жить без всего нового и бесполезного.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	6. Скрыто модератором	+5 +/–
	Сообщение от Попугай Кеша (?), 17-Май-19, 13:13
	Гироскутеры уже не в моде! Моноколеса! Смузи в прошлом, сейчас вегги-детокс-шейки! Биткоин не в моде - даешь БузКоин! Спиннеры не в моде - сейчас просто с бородой ходят аки дедушки!
	Ответить | Правка | Наверх | Cообщить модератору

	21. Скрыто модератором	–6 +/–
	Сообщение от Аноним (21), 17-Май-19, 14:03
	> сейчас просто с бородой ходят аки дедушки! Аки девушки, ты хотел сказать...
	Ответить | Правка | Наверх | Cообщить модератору

	33. Скрыто модератором	+6 +/–
	Сообщение от омномномним (?), 17-Май-19, 15:10
	стрёмные у тебя девушки
	Ответить | Правка | Наверх | Cообщить модератору

	39. Скрыто модератором	+1 +/–
	Сообщение от Аноним (39), 17-Май-19, 15:47
	Зато с медалями. http://susepaste.org/images/46871963.jpg
	Ответить | Правка | Наверх | Cообщить модератору

	49. Скрыто модератором	–2 +/–
	Сообщение от Аноним (49), 17-Май-19, 16:37
	Вот такие https://ru.wikipedia.org/wiki/Кончита_Вурст#/media/File:Conchita_Wurst_-_London_Book_Fair_2015_(17131432956).jpg
	Ответить | Правка | Наверх | Cообщить модератору

	84. Скрыто модератором	+1 +/–
	Сообщение от asdasd (?), 17-Май-19, 18:16
	Так то не девушка, то п*р.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Andrey Mitrofanov (?), 17-Май-19, 13:51
	> а чо, текущая реализация непростая и медленная? Конечно.  Модулем ядра и на ассемблере - всяко быстрее. И руками смержить с дырвером сетевой. Точно быстрее.  Без шуток.  Было в Новостях Опеннета.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	97. "Реализация FastCGI на современном C++"	+3 +/–
	Сообщение от Аноним (97), 17-Май-19, 19:24
	А если на FPGA реализовать всю логику сайта + http + tcp/ip?
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Реализация FastCGI на современном C++"	+4 +/–
	Сообщение от петькаваська (?), 17-Май-19, 15:31
	О какой "текущей реализации" речь? Если об официальной сишной библиотеке, то она уже давно как не поддерживается. Даже сайт fastcgi.com уже давно не доступен. Так что эта либа вполне себе свежак!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Реализация FastCGI на современном C++"	–15 +/–
Сообщение от Аноннн (?), 17-Май-19, 12:58
fastcgi в 2к19 легаси даже бусты уже в http умеют
Ответить | Правка | Наверх | Cообщить модератору

	4. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Аноним (4), 17-Май-19, 13:03
	ну и пользуйте комбайны. а кому-то юникс-вей по душе.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Реализация FastCGI на современном C++"	–3 +/–
	Сообщение от anonnn (?), 18-Май-19, 02:45
	какой-то ненужный у вас юниксвей хттп сейчас более востребован
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Реализация FastCGI на современном C++"	+7 +/–
	Сообщение от kai3341 (ok), 17-Май-19, 13:20
	> fastcgi в 2к19 легаси > даже бусты уже в http умеют Как закончишь делать уроки, разберись в этой статье: https://ru.wikipedia.org/wiki/FastCGI И впредь не торопись хоронить nginx unit
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	129. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от anonnn (?), 18-Май-19, 02:48
	1. к чему эта статья тут? 2. причем тут nginx unit? мне не ясно как вы связали nginx unit (работающий по хттп) и fastcgi
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Реализация FastCGI на современном C++"	–7 +/–
	Сообщение от Аноним (9), 17-Май-19, 13:23
	Видимо кому-то все еще нужно поддерживать древнее барахло, а начав установку, оно потянуло в зависимостях еще более древнее барахло. Вот и написал сервер на скорую руку без каких-либо зависимостей.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	141. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Anonim (??), 18-Май-19, 11:13
	>Видимо кому-то все еще нужно поддерживать древнее барахло, >написанная на современном C++17 ???
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от петькаваська (?), 17-Май-19, 15:34
	Бусты в HTTP. Лол. Вы когда-нибудь пробовали Boost.Beast? Ну и как оно? Всё просто, не правда ли?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	147. "Реализация FastCGI на современном C++"	+4 +/–
	Сообщение от Аноним (147), 18-Май-19, 13:43
	«Всё просто» — это в любом случае не про кресты.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от Аноним (39), 17-Май-19, 15:50
	fastcgi в 2190?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	42. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от петькаваська (?), 17-Май-19, 15:53
	Почему бы и нет?
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от Аноним (50), 17-Май-19, 16:38
	В 2190 Ом? O.o
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (51), 17-Май-19, 16:39
	Ну а чо?
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Sw00p aka Jerom (?), 17-Май-19, 17:13
	grpc не?
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Реализация FastCGI на современном C++"	–4 +/–
	Сообщение от Аноним (39), 17-Май-19, 18:06
	> В 2190 Ом? O.o Все вопросы к начавшему ветку, 2к19 это 2190.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	188. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от runoverheads (ok), 20-Май-19, 00:03
	200019
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Георг (?), 20-Май-19, 18:52
	Ближайший будет красный-коричневый-серый-коричневый-зелёный.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	53. "Реализация FastCGI на современном C++"	+10 +/–
	Сообщение от Anonymoustus (ok), 17-Май-19, 16:45
	> 2к19 Чтоб тебе доктор рецепты и справки на такие даты выписывал, а бухгалтерия — зарплатную ведомость.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

8. "Реализация FastCGI на современном C++"	+/–
Сообщение от Аноним (8), 17-Май-19, 13:22
> через встраивание в приложение в форме заголовочного файла Некорректная формулировка.
Ответить | Правка | Наверх | Cообщить модератору

10. "Реализация FastCGI на современном C++"	+3 +/–
Сообщение от Аноним (10), 17-Май-19, 13:23
Мдя, 2019 год, свежий стандарт плюсов, а поделка уровня студента: зависимость от какой-то левой библиотеки, простыня инструкций по сборке,  кода helloworld на целый экран (про MT вообще молчу, руками потоки надо делать)... Для сравнения, код 4-х летней давности на ржавчине (не для сравнения языков!! на плюсах можно сделать не хуже), просто удобство, краткость, лаконичность: https://docs.rs/fastcgi/1.0.0/fastcgi/
Ответить | Правка | Наверх | Cообщить модератору

	13. "Реализация FastCGI на современном C++"	+8 +/–
	Сообщение от Rustanalz (?), 17-Май-19, 13:38
	Уродский синтаксис у раста...
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от RibiKukan (ok), 17-Май-19, 23:15
	Поделка действительно уровня студента и никакого "свежего стандарта" там нет и близко. Но ты ссылаешься на такую студ-поделку. >https://docs.rs/fastcgi/1.0.0/fastcgi/ Что конкретно тут лаконично? Кроме отсутствия убогих потоков. Хотя нет, макрос говна хуже убогих потоков.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	125. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Ananimususus (?), 18-Май-19, 00:36
	А есть чего нормального на плюсах для FastCGI?
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Реализация FastCGI на современном C++"	+/–
	Сообщение от RibiKukan (ok), 18-Май-19, 01:14
	> А есть чего нормального на плюсах для FastCGI? Может и есть, но я таким убожеством не пользуюсь - не знаю. Я ни разу не работал с подобным(FastCGI) бесполезным легаси-говном.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Ananisimus (?), 18-Май-19, 02:29
	А с чем работаешь?
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Реализация FastCGI на современном C++"	+5 +/–
	Сообщение от _ (??), 18-Май-19, 03:46
	Он членами деревянными на базаре торгует! (С) :-)
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Anonim (??), 18-Май-19, 11:16
	Деревянные -суровое легаси! Им резиновые пришли на смену, ещё в прошлом веке!
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Реализация FastCGI на современном C++"	+/–
	Сообщение от RibiKukan (ok), 18-Май-19, 04:48
	В каком плане? Насколько я понимаю fcgi это такой плебейский ipc. Мало практикую подобное. Так же вроде оно сетевое. Сетевых библиотек множество. На этом уровне работаю в с двумя вещами. uWebSockets - для плебейской коммуникации(оно может в хттп(почти не используется)/ws(используется всегда)). Для внутренней коммуникации - самопал.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	134. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Anaranizimuzus (?), 18-Май-19, 04:54
	>Насколько я понимаю fcgi это такой плебейский ipc. Ага. >uWebSockets >оно может в хттп(почти не используется)/ws(используется всегда) То что нужно, спасибо.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Аноним (189), 20-Май-19, 01:03
	>В каком плане? Насколько я понимаю fcgi это такой плебейский ipc Понимание уровня "не читал, но осуждаю"
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	192. "Реализация FastCGI на современном C++"	+/–
	Сообщение от RibiKukan (ok), 20-Май-19, 04:15
	С чего вдруг, клоун? Я тут не обсуждаю fcgi, а обсуждаю говнокод. Что там автор пытался реализовать - меня волновать не должно. К тому же, для того, что-бы критиковать какое-то говно - мне нужно значить ничего о нём. fcgi по умолчанию является говном. Есть базовая классификация. Если что-то попадает в класс говна, то абсолютно неважно какое это говно. Зелёное, синие и как оно воняет. Факт остаётся фактом. В классификации я не ошибся. Ты можешь попытаться со мною поспорить, но обделаешься тут же.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Реализация FastCGI на современном C++"	+/–
	Сообщение от superkullhacker1997 (?), 20-Май-19, 09:59
	и как тебе не надоело.... напрасно ты тратить свое время... многие годы   ты пытаешься чтото там донести до публики разных форумов, изображая из себя эксперта но тщетно... никто тебя не слышит и всем твои комментарии побоку... посмеялись и забыли... астанавись..
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (194), 20-Май-19, 11:56
	>  обсуждаю говнокод. > что-бы критиковать какое-то говно > fcgi по умолчанию является говном. > Если что-то попадает в класс говна, то абсолютно неважно какое > это говно. Зелёное, синие и как оно воняет. Факт остаётся фактом.   > обделаешься тут же. О! Неужели Царь-Батюшка вернулся и опять несет фекалии в массы?
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

11. "Реализация FastCGI на современном C++"	+3 +/–
Сообщение от X4asd (ok), 17-Май-19, 13:30
не могу понять -- а где тут выход из цикла?       while (true) {         const auto conn = server->accept();         conn->out() << "Content-Type: text/plain" << crlfcrlf;         conn->out() << "Hello from dmitigr::fcgi!" << crlf;         conn->close(); // Optional.       }
Ответить | Правка | Наверх | Cообщить модератору

	17. "Реализация FastCGI на современном C++"	+/–
	Сообщение от СеменСеменыч777 (?), 17-Май-19, 13:52
	> а где тут выход из цикла? выбирайте: 1) выхода нет, эта музыка будет вечной; 2) выход по SIGINT/SIGKILL
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Реализация FastCGI на современном C++"	+/–
	Сообщение от X4asd (ok), 17-Май-19, 14:34
	как тогда понимать --     for (auto& t : threads)       t.join();     server->close(); // Optional. в какой момент код доходит до "server->close();" ?
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от Andrey Mitrofanov (?), 17-Май-19, 14:47
	> как тогда понимать -- Брысь учить C++$((N++)).
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Реализация FastCGI на современном C++"	+/–
	Сообщение от KonstantinB (ok), 19-Май-19, 19:00
	В тот момент, в какой вы этот код напишете. Подставьте вместо true свое условие, соответствующее архитектуре вашего сервера. Это, блин, миниальный пример использования из readme, а не production ready решение. Production ready решение - это, знаете ли, такая штука, которая пишется самостоятельно, а не копипастится с README.md и StackOverflow.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	18. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Andrey Mitrofanov (?), 17-Май-19, 13:53
	> не могу понять -- а где тут выход из цикла? >code] >       while (true) { Та, вот же ОН! --->>>  ^C Как маленький прям.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	34. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Аноним (34), 17-Май-19, 15:12
	SIGTERM не остановит эту программу, SIGKILL нужен.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Реализация FastCGI на современном C++"	+/–
	Сообщение от X4asd (ok), 17-Май-19, 17:29
	> SIGKILL нужен. ну а ещё  можно зайти в gdb, зааттачить и оттуда call close(номер) очень удобно (sarcasm)
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Реализация FastCGI на современном C++"	+3 +/–
	Сообщение от ноунейм (?), 17-Май-19, 17:37
	> SIGTERM не остановит эту программу, SIGKILL нужен. Во-первых, ^C — это SIGINT. Во-вторых почему не остановит? Там где-то обработчики переопределяются?
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	61. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Sw00p aka Jerom (?), 17-Май-19, 17:18
	это же обработка соединения со стороны сервера, без цикла не принял бы другое соединение.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	64. "Реализация FastCGI на современном C++"	+/–
	Сообщение от X4asd (ok), 17-Май-19, 17:28
	> без цикла не принял бы другое соединение. без бесконечного цикла который никогда не прерывается? :-)
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от Sw00p aka Jerom (?), 17-Май-19, 18:02
	> без бесконечного цикла который никогда не прерывается? :-) А вы заранее знаете сколько соединений вы обработаете? На то и серверное сетевое приложение, которое работает фактически вечно для обслуживания запросов. У вас какая-то другая точка зрения как это реализовать? А выход из цикла - равносилен либо аварийному выходу (try catch), либо по сигналу.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Реализация FastCGI на современном C++"	+3 +/–
	Сообщение от Ordu (ok), 17-Май-19, 22:10
	>  На то и серверное сетевое приложение, которое работает фактически вечно для обслуживания запросов. Нет. Реальное серверное приложение имеет документированные возможности, позволяющие остановить его. Возможно ещё перезапустить/перезагрузить конфиги. Серверное приложение _фактически_ не работает вечно, оно регулярно перезапускается после изменения конфигурации или наложения патчей безопасности. > У вас какая-то другая точка зрения как это реализовать? Я могу предложить штуки три альтернативы. while(accept()), server.map_connections(|conn| { ... }) и итератор поверх открываемых соединений. Но вопрос не в том как реализовать, а в мотивации для отказа от той реализации, которая есть. Здесь штатная ситуация (а фейл accept'а -- это, во многих случаях, штатная ситуация) обрабатывается при помощи throw, который используется как нелокальный goto. Такой подход скрывает логику работы, понимание которой существенно для понимания того, как работает этот цикл и что он делает. Это скрытый control flow, относящийся к обработке штатных ситуаций. В результате мы получаем, что сервер написанный с использованием fcgi будет выполнять штатное завершение через нелокальный выход при помощи throw. Это будет работать, но так делать не надо. Делать надо через Either/Result[1]. Это, по-моему, _напрашивающийся_ подход: когда я фанател C'ями, я пытался такую штуку сделать в C, по-сути изобретя её самостоятельно. Я писал какой-то парсер, который возвращал токены и подвыражения, но при этом любая функция могла завершиться с ошибкой. Из-за отсутствия параметризованных типов пришёл к выводу, что всё это конечно круто, но для каждой функции описывать структуру с возвращаемым типом -- это всё же бред. Сейчас я думаю, что может быть можно как-то на кривой козе макросами объехать ограничения языка, но мне просто C более не интересен, поэтому плевать. В Haskell'е же, OCaml'е это совершенно нормальный и естественный ход. И в C++ это должно быть естественным ходом -- для обработки ошибок таким образом не нужен никакие замороки с размоткой стека исключениями, обработка происходит явно и довольно удобно (без этого бесконечного засирания кода if'ами и без необходимости для каждого типа предусматривать значение, которое будет аналогом NULL для указателя), она проверяется статически через систему типов, и блин, всё это настолько естественно, даже непонятно сегодня, почему это было не запилить в C в 70-х годах. Пускай даже для этого потребовался бы специально выточенный костыль из-за отсутствия параметризованных типов. Я не очень понимаю, насколько эти вещи стандартизованы в C++, судя по тексту статьи складывается ощущение, что не стандартизованы, и каждый дpoчит как хочет, а интероперабельность разных API приходится выпиливать лобзиком в каждом конкретном случае. Но там есть ссылки на std::expected и boost::expected, то есть всё не так плохо. [1] https://hackernoon.com/error-handling-in-c-or-why-you-should...
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от Sw00p aka Jerom (?), 18-Май-19, 00:02
	> Реальное серверное приложение имеет документированные возможности, позволяющие остановить его. while (true) - всегда можно остановить! > Серверное приложение _фактически_ не работает вечно while (true) - это "вечный цикл", и если такой код есть в серверном приложении, то значить он работает вечно, а выход из него - по требованию, в том числе и при непредвиденных обстоятельствах. > Я могу предложить штуки три альтернативы. while(accept()), server.map_connections(|conn| { ... }) и итератор поверх открываемых соединений. while(accept()) - тоже самое (с проверкой EAGAIN), что и while (true) { accept() } man ACCEPT(2) Один вызов accept() - обработать одно соединение. Думаю догадаетесь как обработать N соединений. >Но вопрос не в том как реализовать, а в мотивации для отказа от той реализации, которая есть. Человек говорил, что while (true) { accept() } - не правильно применять. Вопрос именно в этом, то есть как обработать N соединений, если accept() обрабатывает одно за вызов. > Здесь штатная ситуация (а фейл accept'а -- это, во многих случаях, штатная ситуация) обрабатывается при помощи throw, который используется как нелокальный goto. ну извините, выше я привел пример как реализовано в пхп, и как написал автор, с той лишь разницей, что автор писал на плюсах. И что не устроила автора комента 1.11, X4asd, который скорее всего плохо знаком с Ц++ и ООП. Он заявил, что там нет условий выхода из вечного цикла, потому-что нет всяких условных конструкций как это обычно делается на СИ. > Такой подход скрывает логику работы, понимание которой существенно для понимания того, как работает этот цикл и что он делает. Это скрытый control flow, относящийся к обработке штатных ситуаций. рассмешили вы меня тут)))) а как же парадигма ООП, прячь все поглубже? ))) вот вам и результат Ц++, а не лапшекод из условных операторов на Си, примеры на Си из пхп выше. >В результате мы получаем, что сервер написанный с использованием fcgi будет выполнять штатное завершение через нелокальный выход при помощи throw. Это будет работать, но так делать не надо. с чего вы взяли, что выход из "вечного цикла" возможен только лишь при нештатных ситуациях? Вы код автора открывали? Выше указал даже номера строк. >но для каждой функции описывать структуру с возвращаемым типом -- это всё же бред О да, это прям как - всё есть класс ) >Я не очень понимаю Ну и я не понимаю, зачем нужны вообще всякие ЯП, когда есть КОП процессора :)
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Ordu (ok), 18-Май-19, 02:57
	> man ACCEPT(2) При чём здесь man accept? Мне казалось очевидно, что речь идёт о том самом server->accept(), но может быть с несколько иным прототипом, чтобы каким-нибудь образом позволить использовать его в качестве условия для while. > Один вызов accept() - обработать одно соединение. Думаю догадаетесь как обработать N > соединений. При написании кода, вопрос не как обработать N соединений, а как написать код так, чтобы понять его через полгода. Чтобы этот код был бы понятен даже тому, кто думает как надо обработать N соединений. Один и тот же алгоритм можно написать тысячью способов, и когда ты будешь читать один из этих способов в коде, тебе надо будет понять, что именно это за способ. Не просто придумать как обработать N соединений, а понять что там напридумывал автор кода. Вопрос в том, как написать код, в котором можно искать баги. Как написать код, о котором можно рассуждать и, в процессе поиска багов, или поиска пути как внести желаемые изменения, доказывать в голове, что "в этой функции не может возникать сегфолт, потому что...", или "этот кусок памяти не может утекать, потому что...". Те возможности, которые язык предоставляет для такого -- это одно из самых важных свойств языка. Всё остальное преходяще. >>Но вопрос не в том как реализовать, а в мотивации для отказа от той реализации, которая есть. > Вопрос именно в этом, то есть как обработать N соединений, если accept() обрабатывает одно за вызов. Как угодно, лишь бы результат отражал бы в коде всё, что нужно про него знать читая этот код. control flow -- это важная вещь, которая должна быть отражена. Структурное программирование не зря придумывали, и никаких longjmp'ов там не было. Некоторые даже с goto боролись до того, что этот самый goto начали выкидывать из языков, местами предлагая взамен совершенно уродские языки. Некоторые даже return выкидывали. С return'ом это пожалуй перебор, но вот longjmp не нужен точно. Если ты конечно не пытаешься на нём реализовать библиотечку coroutine'ов, или ещё какую юзерспейс многозадачность, и используешь longjmp для переключения контекстов. >> Такой подход скрывает логику работы, понимание которой существенно для понимания того, как работает этот цикл и что он делает. Это скрытый control flow, относящийся к обработке штатных ситуаций. > рассмешили вы меня тут)))) а как же парадигма ООП, прячь все поглубже? > ))) вот вам и результат Ц++, а не лапшекод из условных > операторов на Си, примеры на Си из пхп выше. Ну да, возможно это ситуация "заставь дурака богу молиться". Если довести идею инкапсуляции до абсурда, то мы получим чёрную дыру, которая ничего не выпускает наружу и сжирает всё, что оказывается достаточно близко. Идеальный инкапсулятор. Совершенно бесполезный. Но в том-то и дело, что инкапсуляцию, как и любой другой инструмент, следует использовать с умом. Вне зависимости от того, пишем ли мы в ООП парадигме или в какой-то другой. >>В результате мы получаем, что сервер написанный с использованием fcgi будет выполнять штатное завершение через нелокальный выход при помощи throw. Это будет работать, но так делать не надо. > с чего вы взяли, что выход из "вечного цикла" возможен только лишь > при нештатных ситуациях? Вы код автора открывали? Выше указал даже номера > строк. С чего вы взяли, что мы взяли, что выход из вечного цикла возможен лишь при нештатных ситуациях? Мы говорили о том, что штатная ситуация обрабатывается как нештатная. Штатная ситуация обрабатывается нештатным нелокальным goto. >>но для каждой функции описывать структуру с возвращаемым типом -- это всё же бред > О да, это прям как - всё есть класс ) Нет, не всё есть класс. Это совершенно перпендикулярные понятия. Есть значения, которые позволяет передавать информацию. Скажем значение вида struct MaybeToken {    bool ok;    union {        Token tok;        Error err;    } }; позволяет вернуть из функции токен, если он найден, или ошибку, если он не найден. Ошибка при этом может быть содержательной и обрабатывая её мы можем вывести приятное сообщение об ошибке. Или мы можем выполнить какой-нибудь recovery для каких-то из возможных ошибок. Или мы можем преобразовать ошибку к другому типу ошибки, который будет более осмысленным выше, и вернуть её. В C принято выкручиваться всякими разными способами, типа кодировать ошибку отрицательными значениями целочисленной переменной, для которой осмысленны только положительные значения. Или возвращать NULL вместо указателя (таким образом сообщая о факте ошибки, но если причин ошибки может быть несколько и вызывающий код хочет их различать, то это не работает). Или возвращая значение из функции складывая его по переданному указателю, а возвращаемым значением функции выдавать код ошибки. Но это же всё костыли, и естественно возникает желание придумать общий способ для всех. Страуструп придумал исключения, но причёсанняй longjmp как способ обработки ошибок -- это гумно, и опыт C++ показал, что гумно это не только по каким-то замудрёным теоретическим причинам, типа потому что нарушение принципов структурного программирования, но и по вполне практическим. > Ну и я не понимаю, зачем нужны вообще всякие ЯП, когда есть > КОП процессора :) КОП какого процессора?
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Sw00p aka Jerom (?), 18-Май-19, 16:58
	>При чём здесь man accept? Мне казалось очевидно, что речь идёт о том самом server->accept(), но может быть с несколько иным прототипом, чтобы каким-нибудь образом позволить использовать его в качестве условия для while. А притом, что это системный вызов, и без разницы какие тами уровни абстракции поверх. >При написании кода, вопрос не как обработать N соединений, а как написать код так, чтобы понять его через полгода. И через пол года, мы осознаем, что написали дичь какую-то. >Вопрос в том, как написать код, в котором можно искать баги. )) нужно писать код, в котором баги искать не нужно. >Один и тот же алгоритм можно написать тысячью способов, и когда ты будешь читать один из этих способов в коде, тебе надо будет понять, что именно это за способ. И ЯП современные занимаются именно тем как научить 100500 способами простреллить себе ногу, а не один и правильный способ. Про всякие неопределенные поведения я промолчу. Любая формальная система - неполна! (К. Гедель) > что "в этой функции не может возникать сегфолт, потому что...", потому-что, что? А я скажу иначе, сегфолт будет иметь место всегда, когда на одной машине Тьюринга с одной лентой, вы исполняете два алгоритма. Если есть граница (искусственная), то её всегда можно нарушить, как умышленно, так и непредумышленно. А вот границы установленные тем же Богом, нарушить нельзя - почему? >Те возможности, которые язык предоставляет для такого -- это одно из самых важных свойств языка. Всё остальное преходяще. )) язык этого не должен предоставлять, вот естественный язык позволяет выражаться матом, но вы как человек культурный, не принимаете мат, для вас существует граница. Что в итоге, вы из естественного языка предлагаете выпиливать мат? проблема в том, что - где гарантии, что весь язык завтра для вас не будет матершиным? Вы перестанете на нем разговаривать и слышать его? >control flow -- это важная вещь, которая должна быть отражена. Структурное программирование не зря придумывали, и никаких longjmp'ов там не было. control flow - детерминированность, пошаговость (https://ru.wikipedia.org/wiki/%D0%94%D0%...), если есть возможность сделать один шаг, почему не должно быть возможности сделать N шагов за раз, то есть прыжок? >Некоторые даже с goto боролись до того, что этот самый goto начали выкидывать из языков опять забыли про машину Тьюринга, разница между шагом и прыжко - никакая! Борьба с goto - "донкихотство". >Некоторые даже return выкидывали. С return'ом это пожалуй перебор, но вот longjmp не нужен точно. Из ваших рассуждений следует, что найдется по крайней мере один человек, который выкинет весь язык! Что мы наблюдаем на самом деле. >Но в том-то и дело, что инкапсуляцию, как и любой другой инструмент, следует использовать с умом. Вот эту же мысль, попробуйте применить для goto, а не рубить с плеча. >Вне зависимости от того, пишем ли мы в ООП парадигме или в какой-то другой. Если нет никакой зависимости, то с чего мне менять машину Тьюринга на Си? >С чего вы взяли, что мы взяли, что выход из вечного цикла возможен лишь при нештатных ситуациях? В следствии ваших же рассуждений. >Мы говорили о том, что штатная ситуация обрабатывается как нештатная. кхммм тут лучше с пример кода пожалуйста, а то мне кажется что мы говорит о разном. >Штатная ситуация обрабатывается нештатным нелокальным goto. что есть нелокальным? Лента в машине Тьюринга - локальна? >Страуструп придумал исключения, но причёсанняй longjmp как способ обработки ошибок -- это гумно, и опыт C++ показал, что гумно это не только по каким-то замудрёным теоретическим причинам, типа потому что нарушение принципов структурного программирования, но и по вполне практическим. мне было бы очень интересно послушать, что придумали бы вы на месте Страуструпа (серьезно). Как можно разрешить данную проблему? >КОП какого процессора? Того, который собираетесь использовать. Машина Тьюринга одна (ну есть еще машина Поста и т.д.), архитектура того же процессора - одна (Фон Неймановская).
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Ordu (ok), 18-Май-19, 23:03
	>>При чём здесь man accept? Мне казалось очевидно, что речь идёт о том самом server->accept(), но может быть с несколько иным прототипом, чтобы каким-нибудь образом позволить использовать его в качестве условия для while. > А притом, что это системный вызов, и без разницы какие тами уровни > абстракции поверх. Нет, не без разницы. server->accept, вероятно, проводит не только accept на сокете, но ещё и "обмен приветствиями" с клиентом, что можно порождать новые классы ошибок. >>При написании кода, вопрос не как обработать N соединений, а как написать код так, чтобы понять его через полгода. > И через пол года, мы осознаем, что написали дичь какую-то. Я рад, что этот опыт тебе знаком, это значит, что тебе должно быть проще понять о чём я говорю. >>Вопрос в том, как написать код, в котором можно искать баги. > )) нужно писать код, в котором баги искать не нужно. То есть код, который удаляется сразу после написания? :D Все как правило так и делают, то есть пишут код, в котором багов искать не нужно. Я недавно читал исследование, посвящённое исследованию поиску и сравнению факторов, влияющих на частоту появления багов. Из него как раз и вытекает, что при исходном написании кода, как правило багов не так много привносится, но вот при дальнейших модификациях его, особенно если эти модификации выполняются не исходным автором кода, багов привносится гораздо-гораздо больше. Проблема в том, что менять код приходится. И разработчики меняются. Некоторые умудряются обходить этот момент, но вообще это дорогое удовольствие, держать разработчика ответственным за код десятилетиями. Люди меняют место работы, или в случае FOSS теряют интерес к коду или возможность им заниматься. Приходят другие, и вот им хочешь не хочешь приходится разбираться в том, что там было написано, и вносить изменения в существующий код, наполняя его заодно багами. >>Один и тот же алгоритм можно написать тысячью способов, и когда ты будешь читать один из этих способов в коде, тебе надо будет понять, что именно это за способ. > И ЯП современные занимаются именно тем как научить 100500 способами простреллить себе > ногу, а не один и правильный способ. Про всякие неопределенные поведения > я промолчу. Любая формальная система - неполна! (К. Гедель) Знаешь, чем дольше я наблюдаю за людьми цитирующими Гёделя, тем больше я прихожу к выводу, что все эти цитаты исключительно от необразованности. Чтобы цитировать Гёделя, необходимо не понимать Гёделя. >> что "в этой функции не может возникать сегфолт, потому что...", > потому-что, что? А я скажу иначе, сегфолт будет иметь место всегда, когда > на одной машине Тьюринга с одной лентой, вы исполняете два алгоритма. > Если есть граница (искусственная), то её всегда можно нарушить, как умышленно, > так и непредумышленно. А вот границы установленные тем же Богом, нарушить > нельзя - почему? О, Бога ты тоже не зря упомянул. Вижу догматизм в тебе я, и всуе Бога упоминание к лицу тебе. >>Те возможности, которые язык предоставляет для такого -- это одно из самых важных свойств языка. Всё остальное преходяще. > )) язык этого не должен предоставлять, вот естественный язык позволяет выражаться матом, > но вы как человек культурный, не принимаете мат, для вас существует > граница. Что в итоге, вы из естественного языка предлагаете выпиливать мат? > проблема в том, что - где гарантии, что весь язык завтра > для вас не будет матершиным? Вы перестанете на нем разговаривать и > слышать его? Тут ты самым позорным образом путаешь тёплое с мягким. Русский язык предоставляет возможность выражаться красиво и точно. То что он при этом предоставляет философское матерное подмножество, позволяющее выражаться грязно и неточно -- это другой вопрос. >>control flow -- это важная вещь, которая должна быть отражена. Структурное программирование не зря придумывали, и никаких longjmp'ов там не было. > control flow - детерминированность, пошаговость (https://ru.wikipedia.org/wiki/%D0%94%D0%...), > если есть возможность сделать один шаг, почему не должно быть возможности > сделать N шагов за раз, то есть прыжок? Control flow -- это "течение управления", это то как исполнитель программы движется по коду. Если твои словари не объясняют тебе этого, то это много говорит нам о никудышнем качестве твоих словарей, и ничего не сообщает о control flow, потому что мы знаем больше тебя. >>Некоторые даже с goto боролись до того, что этот самый goto начали выкидывать из языков > опять забыли про машину Тьюринга, разница между шагом и прыжко - никакая! > Борьба с goto - "донкихотство". Вот это проявление того самого догматизма. >>Некоторые даже return выкидывали. С return'ом это пожалуй перебор, но вот longjmp не нужен точно. > Из ваших рассуждений следует, что найдется по крайней мере один человек, который > выкинет весь язык! Что мы наблюдаем на самом деле. Да, я наблюдаю вас, действительно. >>Но в том-то и дело, что инкапсуляцию, как и любой другой инструмент, следует использовать с умом. > Вот эту же мысль, попробуйте применить для goto, а не рубить с > плеча. Дитятко, если я упоминаю людей, агитирующих за удаление goto из языка, это не значит, что я сам поддерживаю удаление goto из языка. Так что не надо мне тут нотаций читать, они совершенно не к месту. >>Вне зависимости от того, пишем ли мы в ООП парадигме или в какой-то другой. > Если нет никакой зависимости, то с чего мне менять машину Тьюринга на > Си? Кто тебе сказал, что нет зависимости? Это ещё один пример "смотрю в книгу вижу фигу". >>С чего вы взяли, что мы взяли, что выход из вечного цикла возможен лишь при нештатных ситуациях? > В следствии ваших же рассуждений. One more. >>Мы говорили о том, что штатная ситуация обрабатывается как нештатная. > кхммм тут лучше с пример кода пожалуйста, а то мне кажется что > мы говорит о разном. Код выше. Цикл, из которого штатный выход выполняется через throw/catch. >>Штатная ситуация обрабатывается нештатным нелокальным goto. > что есть нелокальным? Лента в машине Тьюринга - локальна? Если тебе хочется провести аналогию между C++ и лентой в машине Тьюринга, и посмотреть во что превратиться локальность, то тебе надо говорить о локальности символов на ленте. Но я тебе рекомендовал бы, не привлекать аналогии без нужды. Они могут путаться между ногами и мешать процессу мышления. >>Страуструп придумал исключения, но причёсанняй longjmp как способ обработки ошибок -- это гумно, и опыт C++ показал, что гумно это не только по каким-то замудрёным теоретическим причинам, типа потому что нарушение принципов структурного программирования, но и по вполне практическим. > мне было бы очень интересно послушать, что придумали бы вы на месте > Страуструпа (серьезно). Как можно разрешить данную проблему? Я давал выше ссылку на статью обсуждающую throw/catch и предлагающую альтернативы. В той статье есть аж три ссылки с возможными реализациями Either. Пока я искал ту статью я нашёл ещё две реализации Result на C++, которые по-сути то же самое, только с другим названием. Гугли. >>КОП какого процессора? > Того, который собираетесь использовать. Машина Тьюринга одна (ну есть еще машина Поста > и т.д.), архитектура того же процессора - одна (Фон Неймановская). Машина Тьюринга не существует, глупыш. Машина Тьюринга -- целиком и полностью выдумка. Это миф. Сказка. Тьюринг никогда не создавал свою машину в железе, я не уверен что кто-нибудь когда-нибудь создавал её. Машина Тьюринга настолько непрактична, что никто никогда не пытался построить на ней какую-то полезную систему. И уж я совершенно точно не буду писать под машину Тьюринга. Я уж лучше на WebAssembly напишу, который позволяет довольно быструю интерпретацию на любой машине. Но вообще я не люблю интерпретацию, мне бы поближе к железу. И про "собрался использовать" -- это как-то излишне оптимистично. Я использую вперемешку arm64 и amd64. Мне надо чтобы работало и там, и здесь. Иногда я ещё использую avr, которая кладёт болт на фон-Неймана и вся из себя на гарвадской архитектуре, и мне бы хотелось чтобы мои программы работали бы и там тоже. Мало ли мне вдруг приспичит его на avr'ке погонять.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Sw00p aka Jerom (?), 19-Май-19, 02:40
	> Нет, не без разницы. server->accept, вероятно, проводит не только accept на сокете, > но ещё и "обмен приветствиями" с клиентом, что можно порождать новые > классы ошибок. все порождаемые accept "классы" ошибок - описаны, не определенных ошибок нет! > То есть код, который удаляется сразу после написания? :D Лучше сразу пулю в висок. > Знаешь, чем дольше я наблюдаю за людьми цитирующими Гёделя, тем больше я > прихожу к выводу, что все эти цитаты исключительно от необразованности. Чтобы > цитировать Гёделя, необходимо не понимать Гёделя. ок, не образован. > О, Бога ты тоже не зря упомянул. Вижу догматизм в тебе я, > и всуе Бога упоминание к лицу тебе. Догма - аксиома, вспоминаем значение слова. > Тут ты самым позорным образом путаешь тёплое с мягким. Русский язык предоставляет > возможность выражаться красиво и точно. То что он при этом предоставляет > философское матерное подмножество, позволяющее выражаться грязно и неточно -- это другой > вопрос. В смысле "философское матерное" подмножество? И дайте определение "грязно" и "неточно". Тот же goto это ПНХ. > Control flow -- это "течение управления", это то как исполнитель программы движется > по коду. Если твои словари не объясняют тебе этого, то это > много говорит нам о никудышнем качестве твоих словарей, и ничего не > сообщает о control flow, потому что мы знаем больше тебя. "движется" - движение есть последовательность шагов, и как указал прежде - детерминированность. > Вот это проявление того самого догматизма. читаем выше про догму. > Дитятко, если я упоминаю людей, агитирующих за удаление goto из языка, это > не значит, что я сам поддерживаю удаление goto из языка. Так > что не надо мне тут нотаций читать, они совершенно не к > месту. а к какому месту упоминание тех самых людей? и тем более которых не поддерживаете. Определитесь уже, я же говорил мне ваши мысли интересней, а не чужие с которыми вы не согласны. > Кто тебе сказал, что нет зависимости? Это ещё один пример "смотрю в > книгу вижу фигу". ну приведите пример зависимости. > Код выше. Цикл, из которого штатный выход выполняется через throw/catch. try/catch - не штатный выход. > Если тебе хочется провести аналогию между C++ и лентой в машине Тьюринга, > и посмотреть во что превратиться локальность, то тебе надо говорить о > локальности символов на ленте. каждый символ на ленте ограничен своей ячейкой, о какой локальности идёт речь? > Я давал выше ссылку на статью обсуждающую throw/catch и предлагающую альтернативы. В > той статье есть аж три ссылки с возможными реализациями Either. Пока > я искал ту статью я нашёл ещё две реализации Result на > C++, которые по-сути то же самое, только с другим названием. Гугли. повторюсь "мне было бы очень интересно послушать, что придумали бы ВЫ на месте Страуструпа (серьезно)." > Машина Тьюринга не существует, глупыш. Машина Тьюринга -- целиком и полностью выдумка. > Это миф. Сказка. дальше можно не читать!
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Ordu (ok), 19-Май-19, 03:58
	> try/catch - не штатный выход. ДА ЛАДНО! НЕ МОЖЕТ БЫТЬ! > каждый символ на ленте ограничен своей ячейкой, о какой локальности идёт речь? Знаешь, мне надоело объяснять. Думай сам. Если тебе хочется, чтобы я за тебя думал, то мы можем обсудить расценки. > повторюсь "мне было бы очень интересно послушать, что придумали бы ВЫ на > месте Страуструпа (серьезно)." В смысле? Ты хочешь чтобы я всё написанное записал бы в виде аудио, чтобы ты мог послушать? (Серьёзно?)
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от Sw00p aka Jerom (?), 17-Май-19, 18:14
	с пруфами лучше, вот ссылка на fastcgi в пхп https://github.com/php/php-src/blob/master/main/fastcgi.c В строке 1370 int fcgi_accept_request(fcgi_request *req) { #ifdef _WIN32     HANDLE pipe;     OVERLAPPED ov; #endif     while (1) {         if (req->fd < 0) {             while (1) {                 if (in_shutdown) {                     return -1; } и видим там кучу условий выхода при не штатных ситуациях, но мы забыли отметить, что это язык Си, а не плюсы в которых данный код обернут в try-cacth, ну и может где-то там есть обработка сигналов. while (true) {         const auto conn = server->accept();         conn->out() << "Content-Type: text/plain" << crlfcrlf;         conn->out() << "Hello from dmitigr::fcgi!" << crlf;         conn->close(); // Optional.       } При любой нештатной ситуации, цикл отрубится.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	85. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от Sw00p aka Jerom (?), 17-Май-19, 18:17
	https://github.com/dmitigr/fcgi/blob/master/lib/dmitigr/fcgi... Строка 153, и смотрим при каких условиях прервется ваш цикл.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

14. "Реализация FastCGI на современном C++"	+7 +/–
Сообщение от Аноним (14), 17-Май-19, 13:47
Что-то я не понимаю. Почему какая-то поделка ноунейма выкладывается на opennet? Проплачено или что?
Ответить | Правка | Наверх | Cообщить модератору

	20. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Andrey Mitrofanov (?), 17-Май-19, 13:55
	> Что-то я не понимаю. Почему какая-то поделка ноунейма выкладывается на opennet? Проплачено > или что? Конечно. "Оригинальные новостные статьи"(тм)  оплачены щедрыми донорами. Сбор донатов на опеннете -- видел, да?
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (8), 17-Май-19, 14:07
	Так вон они, ниже в конце страницы :)
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Andrey Mitrofanov (?), 17-Май-19, 14:12
	#>>Сбор донатов на опеннете -- видел, да? > Так вон они, ниже в конце страницы :) Эти - не те.  Не видел, значит.  Окэ.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от Аноним (49), 17-Май-19, 17:00
	>Почему какая-то поделка ноунейма выкладывается на opennet? Потому, что open source?
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	116. "Реализация FastCGI на современном C++"	+/–
	Сообщение от segesg (?), 17-Май-19, 22:42
	аффтар сам и выкладывает, пиарится точнее - позорится
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

16. "Реализация FastCGI на современном C++"	–1 +/–
Сообщение от Аноним (16), 17-Май-19, 13:52
Автор, начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n что ли (это я мягко так намекаю про "нужность" дефайнов с crlf). Да и вообще код действительно выглядит как поделка, а использование С++17 в описании - лишь как маркетинговая уловка.
Ответить | Правка | Наверх | Cообщить модератору

	25. "Реализация FastCGI на современном C++"	–3 +/–
	Сообщение от пох (?), 17-Май-19, 14:15
	просто обезьяныш не умеет не обмазываться свеженьким, и c++17 в описании означает не какие-то там достоинства кода, а просто то, что ничем кроме пре-альфа-версии gcc99 это не собирается.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Реализация FastCGI на современном C++"	+4 +/–
	Сообщение от петькаваська (?), 17-Май-19, 15:48
	> Автор, начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n > что ли (это я мягко так намекаю про "нужность" дефайнов с > crlf). > Да и вообще код действительно выглядит как поделка, а использование С++17 в > описании - лишь как маркетинговая уловка. Этими дефайнами автор хочет, вероятно, привести код в соответствии протоколу HTTP, в котором перевод строки строго определён как "\r\n". Так что мат. часть, вероятно, надо учить как раз Вам.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	60. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Аноним (49), 17-Май-19, 17:14
	Что подвигло Тима Бернерса-Ли выбрать для перевода строки \r\n, он же ползовался NIX-like ОС?
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Ordu (ok), 17-Май-19, 17:30
	Я могу предположить. Использование "\r\n" в качестве разделителя строк протокола позволяет в одну строку протокола впихнуть многострочный файл со "\n" в качестве разделителя строк. Но это лишь предположение, реально я не знаю как дело было, просто ты задал вопрос, я задумался над этим, и мне пришёл в голову такой вот возможный ответ.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Аноним (50), 17-Май-19, 17:34
	> Что подвигло Тима Бернерса-Ли выбрать для перевода строки \r\n, он же ползовался NIX-like ОС? А он и не выбирал. Он просто передрал RFC822.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	77. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Аноним (50), 17-Май-19, 18:04
	Ну то есть не передрал, а сослался, конечно. https://tools.ietf.org/html/rfc2068#section-4.1
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от dmitigr (ok), 17-Май-19, 18:26
	Совершенно верно. operator<< - это оператор форматированного вывода. Вызов ostream << "\n" записывает в поток "\r\n" в Windows и "\n" в Unix. Протокол HTTP предписывает использование "\r\n" в качестве разделительной последовательности.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	113. "Реализация FastCGI на современном C++"	+4 +/–
	Сообщение от Аноним (16), 17-Май-19, 21:52
	> автор хочет, вероятно, привести код в соответствии протоколу HTTP, в котором перевод строки строго определён как "\r\n". Так что мат. часть, вероятно, надо учить как раз Вам. Матчасть учить нужно тому, кто не знает про существование std::ios_base::openmode binary, когда ему нужно выводить данные в поток без преобразования символов под конкретную ОС.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	63. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Ordu (ok), 17-Май-19, 17:27
	> начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n И что он там должен увидеть? Может быть это: > There's another function call implied in there if you're going to use std::endl > a) std::cout << "Hello\n"; > b) std::cout << "Hello" << std::endl; > a) calls operator << once. > b) calls operator << twice. ? endl -- это принудительный flush и зависимость перевода строки от платформы под которую собирался код. Зачем это нужно? Сетевые протоколы чётко фиксируют, что используется для терминации строки, и если там написано "\r\n", то тебе даже в unix'е придётся использовать "\r\n".
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	68. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от udro (?), 17-Май-19, 17:33
	> зависимость перевода строки от платформы нет.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Ordu (ok), 17-Май-19, 17:45
	В смысле? Он не выводит "\r\n" в венде? А зачем тогда он нужен такой? Ну вот вообще зачем было заморачиваться добавлять в библиотеку endl, если "\n" нагляднее?
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от udro (?), 17-Май-19, 18:00
	В одном клике от твоей ссылки: https://en.cppreference.com/w/cpp/io/manip/endl > Inserts a newline character into the output sequence os and flushes it as if by calling os.put(os.widen('\n')) followed by os.flush().
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Ordu (ok), 17-Май-19, 19:14
	> В одном клике от твоей ссылки: https://en.cppreference.com/w/cpp/io/manip/endl >> Inserts a newline character into the output sequence os and flushes it as if by calling os.put(os.widen('\n')) followed by os.flush(). Что такое os.widen? Что он там расширяет? Не расширяет ли он заодно '\n' до \r\n, когда нужно? Но даже если ты прав, то это не ответ на вопрос: зачем было вообще добавлять в C++ endl? Какой смысл им пользоваться, если он не даёт ровным счётом ничего? Ради flush? Не проще ли как в C всунуть flush в поток, чтобы он триггерился выводом перевода строки? Или добавить манипулятор потока, который выводит ничего, но выполняет flush -- таким образом не придётся отдельно вызывать метод, что может делать код менее функциональным (в смысле functional programming). О чём думали дизайнеры iostream когда запиливали endl в библиотеку?
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Реализация FastCGI на современном C++"	+/–
	Сообщение от udro (?), 18-Май-19, 11:24
	> Что такое os.widen? Что он там расширяет? Не расширяет ли он заодно '\n' до \r\n, когда нужно? Он — нет. Он только кодировки преобразует, если надо (в UTF-16LE, например, мало ли). А возврат каретки и без него добавляется в ostream. Я хз, чё они курили, но просто вывести \n на винде ещё постараться надо.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от dmitigr (ok), 17-Май-19, 18:04
	> Автор, начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n что ли Здесь автор. Мне не нужно это читать. > (это я мягко так намекаю про "нужность" дефайнов с crlf). Эти дефайны обеспечивают кроссплатформенность кода. > Да и вообще код действительно выглядит как поделка, а использование С++17 в описании - лишь как маркетинговая уловка. Это именно поделка, которой я любезно поделился с сообществом. Кому не нравится, тот просто обходит стороной.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	98. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Sw00p aka Jerom (?), 17-Май-19, 19:35
	О круть, сам автор тут) Хотелось бы одно замечание сделать "namespace dmitigr" простите, но что за "неймдроппинг" такой? как то не серьезно.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от dmitigr (ok), 17-Май-19, 20:42
	Спасибо за комментарий. Странные у Вас вопросы. Резервирование пространства имён для проектов одного автора или компании - обычная практика. Я зарезервировал пространство имён dmitigr для своих проектов. А, например, Niels Lohmann, выбрал пространство имён nlohmann для своих проектов, например namespace nlohmann::json.
	Ответить | Правка | Наверх | Cообщить модератору

19. "Реализация FastCGI на современном C++"	–2 +/–
Сообщение от mumu (ok), 17-Май-19, 13:55
Указатели все разыменовали? За границы буферов не повыходили? Или как обычно?
Ответить | Правка | Наверх | Cообщить модератору

	26. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Andrey Mitrofanov (?), 17-Май-19, 14:15
	> Указатели все разыменовали? За границы буферов не повыходили? Или как обычно? Надо больше замыканий, монадов, строгой типизации и W^X на опенне ^W Microsoft Github-е!
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (49), 23-Май-19, 11:16
	Замыканий лучше коротких.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Andrey Mitrofanov (?), 23-Май-19, 11:24
	> Замыканий лучше коротких. Вот про размер не надо. Разыменовыватели буферов и разграничители указаетелей обидятся же.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от dmitigr (ok), 17-Май-19, 18:05
	Не стоит беспокоится. Все разыменовали и за границы не повыходили. Будут проблемы - обращайтесь. Как обычно.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	110. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Аноним (110), 17-Май-19, 21:20
	Используем стд:стринг, автоуказатели и горя не знаем. А ты как перебиваешься, мир небось замирает, как в матрице у Нео. У него тоже ГЦ неоптимизированный был
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

22. "Реализация FastCGI на современном C++"	+3 +/–
Сообщение от тоже Аноним (ok), 17-Май-19, 14:07
Я таки ничего не знаю за автора этого кода, но на своем персональном сайте он называет себя исключительно "мы". Несколько настораживает...
Ответить | Правка | Наверх | Cообщить модератору

	28. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Andrey Mitrofanov (?), 17-Май-19, 14:19
	> Я таки ничего не знаю за автора этого кода, но на своем > персональном сайте он называет себя исключительно "мы". Несколько настораживает... Может, его кот по клавиатуре прогуливался.  Мы B-P ж не знаем.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Аноним (50), 17-Май-19, 17:29
	Предлагаю скинуться и выслать ему пачку декариса.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

27. Скрыто модератором	–3 +/–
Сообщение от Аноним (27), 17-Май-19, 14:18
С официального сайта: "Нам нравится творить". Вот такие натворят, а потом другим расхлёбывать приходится. За счёт бизнеса (которая платит дважды или даже трижды).
Ответить | Правка | Наверх | Cообщить модератору

29. "Реализация FastCGI на современном C++"	+1 +/–
Сообщение от fgi (?), 17-Май-19, 14:30
неюзабельно уровня студента давайте побольше ваших сладких булочек
Ответить | Правка | Наверх | Cообщить модератору

	43. "Реализация FastCGI на современном C++"	+/–
	Сообщение от мимопроходил (?), 17-Май-19, 16:05
	В каком месте там неюзабельно и в каком месте уровень студента. А то это уже не первый комментарий подобный.
	Ответить | Правка | Наверх | Cообщить модератору

35. "Реализация FastCGI на современном C++"	–2 +/–
Сообщение от Ilya Indigo (ok), 17-Май-19, 15:30
Это будет иметь отношение к mod_fcgid для Apache?
Ответить | Правка | Наверх | Cообщить модератору

	80. "Реализация FastCGI на современном C++"	+/–
	Сообщение от dmitigr (ok), 17-Май-19, 18:07
	Нет. Никакого отношения к mod_fcgid обсуждаемая библиотека не имеет. Вы можете использовать mod_proxy_fcgi для проксирования HTTP-запросов приложению на базе dmitigr_fcgi.
	Ответить | Правка | Наверх | Cообщить модератору

44. "Реализация FastCGI на современном C++"	+4 +/–
Сообщение от НяшМяш (ok), 17-Май-19, 16:07
Вот взъелись вы на дядьку. А он может работу ищет. Сейчас на каждом собеседовании второй вопрос это "есть ли у вас открытые проекты на гитхабе". Поэтому надо выложить хоть что-нибудь, чтобы иметь какой-то вес на собесе.
Ответить | Правка | Наверх | Cообщить модератору

	47. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (51), 17-Май-19, 16:19
	Это классика. 5 стадий принятия неизбежного: отрицание, гнев, торг, депрессия, принятие. Сейчас где-то фаза 1 или 2. Потом полегчает :-)
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Реализация FastCGI на современном C++"	+/–
	Сообщение от dmitigr (ok), 17-Май-19, 18:08
	Спасибо за беспокойство! Работу я не ищу.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

45. "Реализация FastCGI на современном C++"	+2 +/–
Сообщение от Аноним (39), 17-Май-19, 16:10
> DMITIGR_ASSERT((content_len <= max_content_length) && (padding_len <= max_padding_length)); Определение макроса в предлагаемой библиотеке отсутствует. Находится оно в другом месте. Вот такое: #define DMITIGR_ASSERT__(a, t) {                                        \     if (!(a)) {                                                         \       DMITIGR_DOUT__("assertion (%s) failed\n", #a)                     \       if constexpr (t)                                                  \         throw std::logic_error{"assertion (" #a ") failed at " __FILE__ ":" DMITIGR_XSTRINGIZED(__LINE__)}; \     }                                                                   \ } Кто-то может объяснить смысл?
Ответить | Правка | Наверх | Cообщить модератору

	46. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от Аноним (51), 17-Май-19, 16:13
	Может быть какая-то либа-зависимость не установлена?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Аноним (39), 17-Май-19, 17:43
	> Может быть какая-то либа-зависимость не установлена? Если я нашёл определение, значит нашёл и либу (того же автора). Вопрос по сементике самого макроса.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от dmitigr (ok), 17-Май-19, 18:09
	> Вопрос по сементике самого макроса. Что конкретно Вам не ясно?
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Аноним (39), 17-Май-19, 19:57
	>> Вопрос по сементике самого макроса. > Что конкретно Вам не ясно? Не ясно, зачем ассерт бросает исключение, которое: а) из названия не очевидно; б) может быть по недоразумению проигнорировано. Плюс к тому, существует вариант NOTHROW, не приводящий к прерыванию выполнения: #define DMITIGR_DOUT_ALWAYS(...)         DMITIGR_DOUT__(__VA_ARGS__) #define DMITIGR_ASSERT_ALWAYS(a)         DMITIGR_ASSERT__(a, true) #define DMITIGR_ASSERT_NOTHROW_ALWAYS(a) DMITIGR_ASSERT__(a, false) #define DMITIGR_IF_DEBUG__(code) if constexpr (dmitigr::is_debug_enabled) { code } #define DMITIGR_DOUT(...)         { DMITIGR_IF_DEBUG__(DMITIGR_DOUT_ALWAYS(__VA_ARGS__)) } #define DMITIGR_ASSERT(a)         { DMITIGR_IF_DEBUG__(DMITIGR_ASSERT_ALWAYS(a)) } #define DMITIGR_ASSERT_NOTHROW(a) { DMITIGR_IF_DEBUG__(DMITIGR_ASSERT_NOTHROW_ALWAYS(a)) } То есть: либо автор не стал менять название, постепенно модернизируя давно написанное, либо есть скрытый от малознакомых с новыми веяниями С++ (т.е. от меня) смысл. Ну и было интересно, кто что скажет из знатоков, коих тут в избытке.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Реализация FastCGI на современном C++"	–2 +/–
	Сообщение от dmitigr (ok), 17-Май-19, 20:51
	Здесь автор. > Не ясно, зачем ассерт бросает исключение Я используют DMITIGR_ASSERT() вместо стандартного assert() почти везде из-за того, что обычный assert() слишком груб и по умолчанию приводит к завершению программы. DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно. (Мне очевидно, что надо это задокументировать.) > а) из названия не очевидно; Спасибо за замечание. Я задокументирую этот момент! > б) может быть по недоразумению проигнорировано. По недоразумению может быть всё, что угодно. std::logic_error игнорировать не стоит. Это признак бага в программе или в библиотеках, от которых она зависит.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от RibiKukan (ok), 17-Май-19, 23:13
	>Я используют DMITIGR_ASSERT() вместо стандартного assert() Кто тебе мешает использовать нормальные имена? >слишком груб и по умолчанию приводит к завершению программы. Это семантика асерта. >DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно. https://github.com/dmitigr/common/blob/b582b4daf674eed5df1d1... Что это за нелепое говно? Ты вообще понимаешь почему assert макрос? Только для LINE и т.п. Если ты что-то там вещаешь про "модный С++" и пытаешься(нелепо) использовать увиденные где-то трюки(constexpr/constexpr if), то на них логика и должна быть построена. Эта же клоунада - просто клоунада нелепая. Зачем ты превратил макрос в переменную, что-бы потом использовать нахрен ненужный так constexpr if?
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (39), 18-Май-19, 07:22
	>>Я используют DMITIGR_ASSERT() вместо стандартного assert() > Кто тебе мешает использовать нормальные имена? По-простому это называется "глаз замылился". Автору и без имён понятно, что делает макрос. Код выложил, что бы посмотреть на него со стороны. >>слишком груб и по умолчанию приводит к завершению программы. > Это семантика асерта. Да. К счастью, макрос порвал мне шаблон при беглом просмотре исходников, а не при открытии некоего сайта. >>DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно. > https://github.com/dmitigr/common/blob/b582b4daf674eed5df1d1... > Что это за нелепое говно? Ты вообще понимаешь почему assert макрос? Только > для LINE и т.п. Если ты что-то там вещаешь про "модный > С++" и пытаешься(нелепо) использовать увиденные где-то трюки(constexpr/constexpr if), > то на них логика и должна быть построена. Эта же клоунада > - просто клоунада нелепая. Зачем ты превратил макрос в переменную, что-бы > потом использовать нахрен ненужный так constexpr if? constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef. IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Реализация FastCGI на современном C++"	+/–
	Сообщение от RibiKukan (ok), 18-Май-19, 07:40
	>constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef. Полный бред. Я там объяснял почему. >IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода. Причин гениальней это я не слышал. Т.е. constexpr if только для того, чтобы захакать ide? Да, сильно. К тому же, чем это неудобно я так и не понял.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (39), 18-Май-19, 08:26
	>>constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef. > Полный бред. Я там объяснял почему. Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент. >>IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода. > Причин гениальней это я не слышал. Т.е. constexpr if только для того, > чтобы захакать ide? Да, сильно. К тому же, чем это неудобно > я так и не понял. Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Реализация FastCGI на современном C++"	+/–
	Сообщение от RibiKukan (ok), 18-Май-19, 18:01
	>Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент. Технический. Твоя обязанность обосновать. Ты не обосновал, а поиграл в клоуна. Именно это является бредом. >Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app... И, что ты этим показал? Ну кроме того, что ты привык жрать птушное говно.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (39), 18-Май-19, 18:32
	>>Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент. > Технический. Твоя обязанность обосновать. Ты не обосновал, а поиграл в клоуна. Именно > это является бредом. Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой  сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси. >>Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app... > И, что ты этим показал? Ну кроме того, что ты привык жрать > птушное говно. Это была Чорная Магия. Заклинание 1го уровня "зеркало". Всего лишь.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от RibiKukan (ok), 18-Май-19, 20:36
	>Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой  сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси. Клоун, мне без разницы на то кто ты. Ты для меня не отличаешься от любого другого клоуна в интернете. Ты пыль. Твоя задача - либо смешить меня жалкими потугами что-то мне ответить, либо обделаться. Ты выбрал второе, и я даже жалких потуг не увидел. >Это была Чорная Магия. Заклинание 1го уровня "зеркало". Всего лишь. Опять нырнул в дерьмо.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (39), 19-Май-19, 08:57
	>>Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой  сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси. > Клоун, мне без разницы на то кто ты. Знаю. Ты ошибся адресатом, что лишает персонализированные обращения смысла, но для тебя это ничего не меняет. Плоды фантазии безусловно верны для бредящего. > Опять нырнул в дерьмо. Смотри, не задохнись. Зачем ты вообще это делаешь?
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	138. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (39), 18-Май-19, 08:07
	> Здесь автор. >> Не ясно, зачем ассерт бросает исключение > Я используют DMITIGR_ASSERT() вместо стандартного assert() почти везде из-за того, что > обычный assert() слишком груб и по умолчанию приводит к завершению программы. А зачем продолжать её исполнение? > DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно. > (Мне очевидно, что надо это задокументировать.) Виноват, но я принципиально не смотрел документацию, где сказано про зависимости. При этом (в отличии он некоторых читавших) нашёл макрос, поднявшись на уровень выше в репозитории, где увидел common и debug. Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке. >> а) из названия не очевидно; > Спасибо за замечание. Я задокументирую этот момент! Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW? >> б) может быть по недоразумению проигнорировано. > По недоразумению может быть всё, что угодно. std::logic_error игнорировать не стоит. Это > признак бага в программе или в библиотеках, от которых она зависит. The class logic_error defines the type of objects thrown as exceptions to report errors presumably detectable before the program executes, such as violations of logical preconditions or class invariants. Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы. То есть ошибки входных данных. Если же срабатывают ассерты, то запускать программу немножко рано -- она даже собрана на для релиза.
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	140. "Реализация FastCGI на современном C++"	+/–
	Сообщение от dmitigr (ok), 18-Май-19, 10:31
	> А зачем продолжать её исполнение? Здесь больше интересен вопрос: как по-мягче завершить её выполнение? Меня не устраивает заверешние через std::abort(), поэтому DMITIGR_ASSERT() генерирует std::logic_error, что предоставляет возможность самому приложению решать как именно закругляться (или не закругляться). > Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке. Так и было. Раньше он назывался DMITIGR_INTERNAL_ASSERT(). Но я не вижу в этом больше смысла. > Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW? Вариант с "THROW" - это и есть DMITIGR_ASSERT(). > Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы. Это и есть баг. И всякий баг - это логическая ошибка. Можно ввести класс Bug, унаследованный от std::logic_error, но в этом смысл околонулевой - о классе std::logic_error знают все, кто пишет на C++.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (39), 18-Май-19, 11:32
	>> А зачем продолжать её исполнение? > Здесь больше интересен вопрос: как по-мягче завершить её выполнение? Меня не устраивает > заверешние через std::abort(), поэтому DMITIGR_ASSERT() генерирует std::logic_error, > что предоставляет возможность самому приложению решать как именно закругляться (или не > закругляться). Наверное, прежде всего для этого необходимо обеспечить 100% гарантии вызова обработчика исключений, ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии. >> Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке. > Так и было. Раньше он назывался DMITIGR_INTERNAL_ASSERT(). Но я не вижу в > этом больше смысла. >> Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW? > Вариант с "THROW" - это и есть DMITIGR_ASSERT(). При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :) >> Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы. > Это и есть баг. И всякий баг - это логическая ошибка. Можно > ввести класс Bug, унаследованный от std::logic_error, но в этом смысл околонулевой > - о классе std::logic_error знают все, кто пишет на C++. __builtin_trap() - ошибка физическая (на x86 транслируется в UD2). SIGILL логическая. Тоже генерируют исключение, которое можно попробовать поймать, но перепутать его с подмножеством ошибок std::logic_error -- надо постараться.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Реализация FastCGI на современном C++"	+/–
	Сообщение от dmitigr (ok), 18-Май-19, 11:46
	> Наверное, прежде всего для этого необходимо обеспечить 100% гарантии вызова обработчика исключений, ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии. Обработчики исключений, которые пересекают границы библиотек, определяются в приложениях. > ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии. О каком неконсистентном состоятии речь? > При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :) Он называется DMITIGR_ASSERT(), а не ASSERT() или Assert(). Поэтому судить о семантике следует либо из документации, либо из определения. >  __builtin_trap() - ошибка физическая (на x86 транслируется в UD2). SIGILL логическая. Тоже генерируют исключение, которое можно попробовать поймать, но перепутать его с подмножеством ошибок std::logic_error -- надо постараться. Не совсем понял к чему это, но исключения std::logic_error ловятся стандартным образом.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (39), 18-Май-19, 15:24
	>> При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :) > Он называется DMITIGR_ASSERT(), а не ASSERT() или Assert(). Поэтому судить о семантике > следует либо из документации, либо из определения. Следует? Автору виднее. Автор может поступать, как считает нужным. Сам.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Реализация FastCGI на современном C++"	+/–
	Сообщение от dmitigr (ok), 18-Май-19, 17:01
	Следует. С чего вдруг некий DMITIGR_ASSERT() должен повторять семантику стандартного assert()? Наличие слова "ASSERT" в названии к этому не обязывает. Мне не понятно, зачем вообще Вам этот макрос? Это деталь реализации. Пользователям библиотеки она совершенно не нужна. Если Вы собираетесь поучаствовать в разработке, то Вы уже знаете что это за макрос, благо его определение занимает 5 строчек. Спасибо за дискуссию!
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (39), 18-Май-19, 18:18
	> Следует. С чего вдруг некий DMITIGR_ASSERT() должен повторять семантику стандартного assert()? "Должен" не то слово. Есть ожидания пользователя, читателя кода. Если они расходится положением дел, возможны варианты (принять/не принять). > Мне не понятно, зачем вообще Вам этот макрос? Интерес представляет в первую очередь ход мыслей автора. Если глаз цепляется, значит такое наверняка повстречается где-то ещё. Чем больше задаю таких глупых вопросов, тем проще потом сориентироваться в новом коде. Документация не всегда в наличии, как и исходники. Благодарю за разъяснения.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Anonymoustus (ok), 18-Май-19, 16:29
	> DMITIGR_ > DMITIGR_ > DMITIGR_ > DMITIGR_ > DMITIGR_ > DMITIGR_ > DMITIGR_ > DMITIGR_ > DMITIGR_ > DMITIGR_ Аффтару нимб не жмёт?
	Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

48. "Реализация FastCGI на современном C++"	+/–
Сообщение от Аноним (48), 17-Май-19, 16:27
FastCGI настолько простой протокол что только ленивый студент не реализовывал его на своем любимом языке
Ответить | Правка | Наверх | Cообщить модератору

52. "Реализация FastCGI на современном C++"	+1 +/–
Сообщение от Аноним (50), 17-Май-19, 16:40
In file included from /home/dmitry/tmp/fcgi/lib/dmitigr/fcgi/basics.hpp:62,                  from /home/dmitry/tmp/fcgi/lib/dmitigr/fcgi.hpp:26,                  from /home/dmitry/tmp/fcgi/lib/dmitigr/fcgi.cpp:7: /home/dmitry/tmp/fcgi/lib/dmitigr/fcgi/basics.cpp:9:10: fatal error: dmitigr/common/debug.hpp: Нет такого файла или каталога #include <dmitigr/common/debug.hpp>           ^~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Автор, ну ты понел.
Ответить | Правка | Наверх | Cообщить модератору

	57. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (57), 17-Май-19, 17:08
	пишут что нужно `common` имени дмитрия ингишина иметь: https://github.com/dmitigr/fcgi/blob/master/README.md#depend...
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Аноним (50), 17-Май-19, 17:27
	То есть он даже поиск библиотеки в cmake не осилил? Молодец какой. Дальше смотреть не вижу смысла.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от dmitigr (ok), 17-Май-19, 18:21
	Кто-то не осилил прочитать документацию. Дальше смотреть нет смысла. В действительности, всё что требуется, это установить библиотеку dmitigr_common. Всё остальное CMake сделает автоматически.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Аноним (50), 17-Май-19, 19:01
	Установить куда? А если я её в нестандартный префикс хочу, чтобы систему не поганить? CMake должен делать автоматически не «всё остальное», но и поиск библиотеки тоже. Если её нет — вывести внятное сообщение об ошибке. А тут конфигурация типа прошла успешно, а оказывается — зависимостей не хватает!
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Реализация FastCGI на современном C++"	+/–
	Сообщение от dmitigr (ok), 17-Май-19, 19:09
	Спасибо за отзыв. CMake ищет библиотеку автоматически. Я только что попробовал сконфигурировать dmitigr_fcgi без установленного dmitigr_common. Вот реакция CMake: Building of shared library is enabled. Build type is Debug Building of tests is enabled -- Could NOT find dmitigr_common (missing: dmitigr_common_DIR) -- Could NOT find dmitigr_common (missing: dmitigr_common_DIR) CMake Warning at cmake/dmitigr_package_finder.cmake:31 (find_package):   By not providing "Finddmitigr_common.cmake" in CMAKE_MODULE_PATH this   project has asked CMake to find a package configuration file provided by   "dmitigr_common", but CMake did not find one.   Could not find a package configuration file provided by "dmitigr_common"   with any of the following names:     dmitigr_commonConfig.cmake     dmitigr_common-config.cmake   Add the installation prefix of "dmitigr_common" to CMAKE_PREFIX_PATH or set   "dmitigr_common_DIR" to a directory containing one of the above files.  If   "dmitigr_common" provides a separate development package or SDK, be sure it   has been installed. Call Stack (most recent call first):   cmake/FindCommon.cmake:21 (include)   CMakeLists.txt:189 (find_package)
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Аноним (50), 17-Май-19, 19:23
	Действительно, сообщение есть, я его не заметил. Но это всего лишь warning, статус завершения 0, Makefile создался, в конце: Using  library -- Configuring done -- Generating done -- Build files have been written to: /home/anon/fcgi/build Потому выше по логу и не смотрел. Должно быть завершение с ошибкой, если зависимость обязательная.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от dmitigr (ok), 17-Май-19, 23:06
	Спасибо, исправил! Эта регрессия появилась из-за относительно давнего рефакторинга. Я её и не замечал. PS. Ведь можно же как-то проще сообщать о недочётах. А то чуть что, так сразу "автор неосилил". Не этично.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Anonymoustus (ok), 18-Май-19, 16:31
	> PS. Ведь можно же как-то проще сообщать о недочётах. А то чуть > что, так сразу "автор неосилил". Не этично. Это опенсорс! Никто никому ничего не должен™.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от dmitigr (ok), 18-Май-19, 16:50
	> Это опенсорс! Никто никому ничего не должен™. Хм. А какое Вы имеете отношение к open source? Разве Вы что-то сотворили?
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (198), 22-Май-19, 06:40
	You must be new here.
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

54. "Реализация FastCGI на современном C++"	+11 +/–
Сообщение от Аноним (57), 17-Май-19, 16:50
Список новостей: - Microsoft открыл код библиотеки векторного поиска, используемой в Bing - Дима Игришин сделал git push - Фонд свободного ПО сертифицировал звуковые карты и WiFi-адаптеры ThinkPenguin
Ответить | Правка | Наверх | Cообщить модератору

	124. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Аноним (124), 18-Май-19, 00:19
	Ну и норм
	Ответить | Правка | Наверх | Cообщить модератору

55. "Реализация FastCGI на современном C++"	+/–
Сообщение от Anonymouss (?), 17-Май-19, 16:55
Судя по коду это fcgi, а не fastcgi. какой смысл тогда?
Ответить | Правка | Наверх | Cообщить модератору

	87. "Реализация FastCGI на современном C++"	+/–
	Сообщение от dmitigr (ok), 17-Май-19, 18:22
	Это реализация FastCGI. FCGI - это сокращение FastCGI.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от eRIC (ok), 17-Май-19, 19:36
	dmitigr, бенчмарки вашей реализации есть для сравнения?
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Реализация FastCGI на современном C++"	+/–
	Сообщение от dmitigr (ok), 17-Май-19, 20:56
	Бенчмарков нет. Я сравнивал с libfcgi. dmitigr_fcgi быстрее где-то на 15-20%. Я знаю ещё несколько мест в своей реализации для оптимизации и прироста производительности. В скором времени улучшу.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от eRIC (ok), 17-Май-19, 21:40
	> Бенчмарков нет. Я сравнивал с libfcgi. dmitigr_fcgi быстрее где-то на 15-20%. Я > знаю ещё несколько мест в своей реализации для оптимизации и прироста > производительности. В скором времени улучшу. интересно. с активным по сей день с библиотекой https://github.com/eddic/fastcgipp (C++14) попробуйте произвести бенчмарки, будет очень интересно. в будущем надеюсь в проекте бенчмарк отчеты появятся.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от Anonymouss (?), 17-Май-19, 20:13
	Заявление ничем не подкрепленное? Ну ок. https://www.apachelounge.com/viewtopic.php?t=4385
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	106. "Реализация FastCGI на современном C++"	+/–
	Сообщение от dmitigr (ok), 17-Май-19, 20:34
	Библиотека dmitigr_fcgi реализована в соответствии со спецификацией FastCGI. См. http://www.mit.edu/afs.new/sipb/user/yandros/doc/specs/fcgi-... FCGI - это сокращённое название FastCGI. Apache mod_fcgi или mod_fastcgi не имеют никакого отношения к моей библиотеке.
	Ответить | Правка | Наверх | Cообщить модератору

92. "Реализация FastCGI на современном C++"	+3 +/–
Сообщение от eRIC (ok), 17-Май-19, 19:09
Многие тут комментаторы от Бога так и не понимают в чем изюминка этой реализации FastCGI, дело в " написанная на современном C++17" - "The FastCGI implementation on modern C++". Делая выводы можно сказать что она как алтернативная реализация по спецификации FastCGI придаст прирост в производительности, легкости и т.д., что позволяет дать современные последние версии компиляторы c поддержкой C++17 (ведь язык программирования C++ тоже не стоит на месте и совершенствуется) P.S: кстати, если кто-то будет искать закрытый сайт FastCGI, можете посмотреть в архиве: https://fastcgi-archives.github.io/
Ответить | Правка | Наверх | Cообщить модератору

	94. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Ordu (ok), 17-Май-19, 19:20
	> Многие тут комментаторы от Бога так и не понимают в чем изюминка Многие комментаторы здесь делают сознательные усилия, чтобы не понимать. Всё комментирование здесь сводится к специальной олимпиаде на тему, кто самым возмутительным образом не поймёт, что написано.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от eRIC (ok), 17-Май-19, 19:21
	> Многие комментаторы здесь делают сознательные усилия, чтобы не понимать. Всё комментирование > здесь сводится к специальной олимпиаде на тему, кто самым возмутительным образом > не поймёт, что написано. особенно (A|O)нонимы :)
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от Sw00p aka Jerom (?), 17-Май-19, 19:40
	> как алтернативная реализация спецификации FastCGI Кхммм, спецификации? вы серьезно? Альтернативная реализация ---> по <--- спецификации FastCGI!
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	102. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от eRIC (ok), 17-Май-19, 19:45
	> Кхммм, спецификации? вы серьезно? Альтернативная реализация ---> по <--- спецификации > FastCGI! да, верно, имелось что это не новая спецификация FastCGI, а имплементация его
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (50), 17-Май-19, 19:44
	> Делая выводы можно сказать что она как алтернативная реализация спецификации FastCGI придаст прирост в производительности, легкости и т.д. Из чего и каким образом можно сделать такие выводы? > усоверешенствовыется Ты б свой русский посвершенствовывал, что ли.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	103. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от eRIC (ok), 17-Май-19, 19:50
	>> усоверешенствовыется > Ты б свой русский посвершенствовывал, что ли. после чтения толкового словаря по русскому языку, исправлено. старую информацию смотрите, нажмите F5 :)
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Sw00p aka Jerom (?), 17-Май-19, 21:45
	Бывает, когда в мыслях проговариваешь, а в комментарии думаешь что написал, да, да, нажимаем сразу отправить потом только видим ошибку :)
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	114. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от Аноним (16), 17-Май-19, 22:04
	> on modern C++ Писать по-английски – это вообще-то не слова по словарю с вашего языка переводить.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

Часть нити удалена модератором

	186. "Реализация FastCGI на современном C++"	–1 +/–
	Сообщение от Аноним (186), 19-Май-19, 18:06
	>>>> Зачем ты, клоун, пытаешься защищать свою жопу >>> Веришь ли, но в природе это норма. Пока мы жили на деревьях, >>> для таковой защиты имелся даже специальный орган -- хвост. Потом появились >>> разум, этикет, одежда. >> И когда же вы жили на деревьях? > До момента пока не изрёк Господь Бог "сотворим человека по образу Нашему > и по подобию Нашему". Креационизм ничем не хуже утверждений, что хвост предки человеков потеряли из-за появления разума, этикета и одежды. Кстати, уже давно считается, что у человеков и бибизьян был общий предок. Так же известно, что далеко не все бибизьяны живут на деревьях. Строение человеческой стопы и отсутсвие хвоста, как бы, намекают немного сведующим в биологии, где именно жили предки человеков.
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

	190. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (189), 20-Май-19, 01:13
	>Делая выводы можно сказать что она как алтернативная реализация по спецификации FastCGI придаст прирост в производительности, легкости и т.д., что позволяет дать современные последние версии компиляторы c поддержкой C++17 (ведь язык программирования C++ тоже не стоит на месте и совершенствуется) Трудно представить, какой приницпиальный выигрыш в производительности может быть у реализации FastCGI на С++ по сравнению с С, не говоря у же о С++17 по сравнению со старым С++. Там же простой бинарный протокол, который парсится обычными сишными структурами
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

121. "Реализация FastCGI на современном C++"	+/–
Сообщение от Аноним (121), 17-Май-19, 23:55
cppcms же есть
Ответить | Правка | Наверх | Cообщить модератору

	132. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (132), 18-Май-19, 04:34
	Зачем есть же libevent с HTTP поддержкой
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (121), 20-Май-19, 20:07
	Во-первых, топик про FastCGI. Во-вторых, где libevent, а где cppcms.. В последней есть всё для создания полноценного web-бэкенда (транспорт, маршрутизация запросов на исполняющий код, пулы рабочих потоков, сессии и сопутствующие шифрование и hmac-и, json, журналирование и проч.), и оно уже на плюсах и используется в проде.
	Ответить | Правка | Наверх | Cообщить модератору

146. "Реализация FastCGI на современном C++"	+8 +/–
Сообщение от Аноним (146), 18-Май-19, 12:20
Непонятно откуда столько негатива в коментах. Люди, вы если с чем-то несогласны, пишите аргументировано. Давайте уже перестанем сеять среди нашего общества негатив. Советую к прочтению: en: http://paulgraham.com/disagree.html ru: https://web.archive.org/web/20120505004501/http://translated.../
Ответить | Правка | Наверх | Cообщить модератору

	164. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от eRIC (ok), 18-Май-19, 19:14
	+1 наследие СССР :)
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Аноним (4), 19-Май-19, 12:43
	чушь. при СССР технари к технарям оч.хорошо относились. почитайте сообщения на форумах/эхах 90х годов (это как раз поколение выросшее в СССР) - все оч вежливо, никакой ругани, ехиндичиства и т.д. те, о ком вы говорите совсем другое поколение.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от eRIC (ok), 19-Май-19, 16:42
	> те, о ком вы говорите совсем другое поколение. ну я как раз имел в виду не технарей, которые в годы СССР работали, а последствия распада СССР, приходом демократии, и приходом диванных критиков :)
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Реализация FastCGI на современном C++"	+2 +/–
	Сообщение от Аноним (189), 20-Май-19, 01:16
	Поколение Пепси
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от eRIC (ok), 20-Май-19, 13:35
	> Поколение Пепси точно +1
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Аноним (49), 23-Май-19, 11:55
	А сейчас смузи.
	Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

	199. "(offtopic) 'как не соглашаться'"	+/–
	Сообщение от Michael Shigorin (ok), 22-Май-19, 12:43
	> Советую к прочтению: > en: http://paulgraham.com/disagree.html > ru: https://web.archive.org/web/20120505004501/http://translated... Спасибо за статью Полу, а Вам -- за ссылку!
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

150. "Реализация FastCGI на современном C++"	+6 +/–
Сообщение от Филимон Печальный (?), 18-Май-19, 16:28
Народ, вы чего ? Человек написал библиотеку, выложил бесплатно, никого использовать её не заставляет... Где здесь повод исходить говном ? Это массовый психоз какой-то :-(
Ответить | Правка | Наверх | Cообщить модератору

	163. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от Аноним (39), 18-Май-19, 18:52
	Да какой массовый? Парочка типичных персонажей изображают толпу.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Реализация FastCGI на современном C++"	+/–
	Сообщение от Anonymoustus (ok), 18-Май-19, 20:41
	Утешься прекрасным: https://www.govnokod.ru/25608
	Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

	178. "Реализация FastCGI на современном C++"	+1 +/–
	Сообщение от souryogurt (ok), 19-Май-19, 05:22
	Лично мне просто непонятно почему это в новостях на опеннет. Разве это какая-то значимая для open source новость? Можно было бы на форуме ее разместить, если хочется найти своих пользователей или разработчиков, или просто пропиарится для чего-то еще. Ну и глядя на то, как оформлена репа и личный блог автора, так и тянет тролить. Везде МЫ во всех названиях присутутсвует dmitrygr, и т.д. Доходит до абсурда. Вы только прочитайте в слух первую строчку документации: "Client programs that use Dmitigr Fcgi must include header file dmitigr/fcgi.hpp. and must link with dmitigr_fcgi (or the debug build - dmitigr_fcgid) if Dmitigr Fcgi is used as a regular library." Другими словами, неймспейс неоч :) Бог создал землю за шесть дней. Дмитрий Ингришин создал FastCGI за пять.
	Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

204. "Реализация FastCGI на современном C++"	+/–
Сообщение от greenwar (ok), 13-Май-20, 10:15
забота о пользователе зашкаливает... >> CMake Error at CMakeLists.txt:5 (cmake_minimum_required): >>  CMake 3.17 or higher is required.  You are running version 3.13.4 >> sudo apt install cmake >> Уже установлен пакет cmake самой новой версии (3.13.4-1). (debian buster)
Ответить | Правка | Наверх | Cообщить модератору

205. "Реализация FastCGI на современном C++"	+/–
Сообщение от greenwar (ok), 13-Май-20, 10:22
3.17 это самая последняя версия cmake на офф.сайте (3.17.2) её только вручную ставить чё без cmake никак чтоли не поставить это чудо инженерной мысли?
Ответить | Правка | Наверх | Cообщить модератору

206. "Реализация FastCGI на современном C++"	+/–
Сообщение от greenwar (ok), 13-Май-20, 11:34
а это чё: >> /usr/bin/ld: /tmp/ccf5Ifs9.o: in function `main': >> fcgi-hello.cpp:(.text+0x52): undefined reference to `dmitigr::fcgi::Listener_options::make(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, int)' >> /usr/bin/ld: fcgi-hello.cpp:(.text+0x11d): undefined reference to `dmitigr::fcgi::crlfcrlf(std::ostream&)' >> collect2: error: ld returned 1 exit status при попытке скомпилировать dmitigr/fcgi/test/fcgi/fcgi-hello.cpp
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема