Доступна (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.ru/opennews/art.shtml?num=50699
а чо, текущая реализация непростая и медленная?
В тексте новости нет сравнения сложности и производительности, есть лишь утверждение что библиотека проста и производительна, поэтому твой вопрос не логичен.
Как и сами утверждения в новости, не?
и бенчмарков примитивных не вижу
Зато эта для тех, кто крутит спинеры, деньги хранит в биткоинах, курит вейп, каждую неделю посещает барбершоп, пьёт исключительно смузи и по улице передвигается только на гироскутере. Короче не может жить без всего нового и бесполезного.
Гироскутеры уже не в моде! Моноколеса!
Смузи в прошлом, сейчас вегги-детокс-шейки!
Биткоин не в моде - даешь БузКоин!
Спиннеры не в моде - сейчас просто с бородой ходят аки дедушки!
> сейчас просто с бородой ходят аки дедушки!Аки девушки, ты хотел сказать...
стрёмные у тебя девушки
Зато с медалями.
Вот такие https://ru.wikipedia.org/wiki/Кончита_Вурст#/media/File:Conchita_Wurst_-_London_Book_Fair_2015_(17131432956).jpg
Так то не девушка, то п*р.
> а чо, текущая реализация непростая и медленная?Конечно. Модулем ядра и на ассемблере - всяко быстрее.
И руками смержить с дырвером сетевой.
Точно быстрее. Без шуток. Было в Новостях Опеннета.
А если на FPGA реализовать всю логику сайта + http + tcp/ip?
О какой "текущей реализации" речь? Если об официальной сишной библиотеке, то она уже давно как не поддерживается. Даже сайт fastcgi.com уже давно не доступен. Так что эта либа вполне себе свежак!
fastcgi в 2к19 легасидаже бусты уже в http умеют
ну и пользуйте комбайны. а кому-то юникс-вей по душе.
какой-то ненужный у вас юниксвей
хттп сейчас более востребован
> fastcgi в 2к19 легаси
> даже бусты уже в http умеютКак закончишь делать уроки, разберись в этой статье: https://ru.wikipedia.org/wiki/FastCGI
И впредь не торопись хоронить nginx unit
1. к чему эта статья тут?
2. причем тут nginx unit?
мне не ясно как вы связали nginx unit (работающий по хттп) и fastcgi
Видимо кому-то все еще нужно поддерживать древнее барахло, а начав установку, оно потянуло в зависимостях еще более древнее барахло. Вот и написал сервер на скорую руку без каких-либо зависимостей.
>Видимо кому-то все еще нужно поддерживать древнее барахло,
>написанная на современном C++17???
Бусты в HTTP. Лол. Вы когда-нибудь пробовали Boost.Beast? Ну и как оно? Всё просто, не правда ли?
«Всё просто» — это в любом случае не про кресты.
fastcgi в 2190?
Почему бы и нет?
В 2190 Ом? O.o
Ну а чо?
grpc не?
> В 2190 Ом? O.oВсе вопросы к начавшему ветку, 2к19 это 2190.
200019
Ближайший будет красный-коричневый-серый-коричневый-зелёный.
> 2к19Чтоб тебе доктор рецепты и справки на такие даты выписывал, а бухгалтерия — зарплатную ведомость.
> через встраивание в приложение в форме заголовочного файлаНекорректная формулировка.
Мдя, 2019 год, свежий стандарт плюсов, а поделка уровня студента: зависимость от какой-то левой библиотеки, простыня инструкций по сборке, кода helloworld на целый экран (про MT вообще молчу, руками потоки надо делать)...Для сравнения, код 4-х летней давности на ржавчине (не для сравнения языков!! на плюсах можно сделать не хуже), просто удобство, краткость, лаконичность:
https://docs.rs/fastcgi/1.0.0/fastcgi/
Уродский синтаксис у раста...
Поделка действительно уровня студента и никакого "свежего стандарта" там нет и близко. Но ты ссылаешься на такую студ-поделку.>https://docs.rs/fastcgi/1.0.0/fastcgi/
Что конкретно тут лаконично? Кроме отсутствия убогих потоков. Хотя нет, макрос говна хуже убогих потоков.
А есть чего нормального на плюсах для FastCGI?
> А есть чего нормального на плюсах для FastCGI?Может и есть, но я таким убожеством не пользуюсь - не знаю. Я ни разу не работал с подобным(FastCGI) бесполезным легаси-говном.
А с чем работаешь?
Он членами деревянными на базаре торгует! (С) :-)
Деревянные -суровое легаси! Им резиновые пришли на смену, ещё в прошлом веке!
В каком плане? Насколько я понимаю fcgi это такой плебейский ipc. Мало практикую подобное. Так же вроде оно сетевое. Сетевых библиотек множество. На этом уровне работаю в с двумя вещами. uWebSockets - для плебейской коммуникации(оно может в хттп(почти не используется)/ws(используется всегда)). Для внутренней коммуникации - самопал.
>Насколько я понимаю fcgi это такой плебейский ipc.Ага.
>uWebSockets
>оно может в хттп(почти не используется)/ws(используется всегда)То что нужно, спасибо.
>В каком плане? Насколько я понимаю fcgi это такой плебейский ipcПонимание уровня "не читал, но осуждаю"
С чего вдруг, клоун? Я тут не обсуждаю fcgi, а обсуждаю говнокод. Что там автор пытался реализовать - меня волновать не должно. К тому же, для того, что-бы критиковать какое-то говно - мне нужно значить ничего о нём. fcgi по умолчанию является говном. Есть базовая классификация. Если что-то попадает в класс говна, то абсолютно неважно какое это говно. Зелёное, синие и как оно воняет. Факт остаётся фактом.В классификации я не ошибся. Ты можешь попытаться со мною поспорить, но обделаешься тут же.
и как тебе не надоело.... напрасно ты тратить свое время... многие годы ты пытаешься чтото там донести до публики разных форумов, изображая из себя эксперта но тщетно... никто тебя не слышит и всем твои комментарии побоку... посмеялись и забыли... астанавись..
> обсуждаю говнокод.
> что-бы критиковать какое-то говно
> fcgi по умолчанию является говном.
> Если что-то попадает в класс говна, то абсолютно неважно какое
> это говно. Зелёное, синие и как оно воняет. Факт остаётся фактом.
> обделаешься тут же.О! Неужели Царь-Батюшка вернулся и опять несет фекалии в массы?
не могу понять -- а где тут выход из цикла?
while (true) {
const auto conn = server->accept();
conn->out() << "Content-Type: text/plain" << crlfcrlf;
conn->out() << "Hello from dmitigr::fcgi!" << crlf;
conn->close(); // Optional.
}
> а где тут выход из цикла?выбирайте:
1) выхода нет, эта музыка будет вечной;
2) выход по SIGINT/SIGKILL
как тогда понимать --
for (auto& t : threads)
t.join();server->close(); // Optional.
в какой момент код доходит до "server->close();" ?
> как тогда понимать --Брысь учить C++$((N++)).
В тот момент, в какой вы этот код напишете.Подставьте вместо true свое условие, соответствующее архитектуре вашего сервера. Это, блин, миниальный пример использования из readme, а не production ready решение.
Production ready решение - это, знаете ли, такая штука, которая пишется самостоятельно, а не копипастится с README.md и StackOverflow.
> не могу понять -- а где тут выход из цикла?
>code]
> while (true) {Та, вот же ОН! --->>> ^C
Как маленький прям.
SIGTERM не остановит эту программу, SIGKILL нужен.
> SIGKILL нужен.ну а ещё можно зайти в gdb, зааттачить и оттуда
call close(номер)очень удобно (sarcasm)
> SIGTERM не остановит эту программу, SIGKILL нужен.Во-первых, ^C — это SIGINT. Во-вторых почему не остановит? Там где-то обработчики переопределяются?
это же обработка соединения со стороны сервера, без цикла не принял бы другое соединение.
> без цикла не принял бы другое соединение.без бесконечного цикла который никогда не прерывается? :-)
> без бесконечного цикла который никогда не прерывается? :-)А вы заранее знаете сколько соединений вы обработаете? На то и серверное сетевое приложение, которое работает фактически вечно для обслуживания запросов. У вас какая-то другая точка зрения как это реализовать? А выход из цикла - равносилен либо аварийному выходу (try catch), либо по сигналу.
> На то и серверное сетевое приложение, которое работает фактически вечно для обслуживания запросов.Нет. Реальное серверное приложение имеет документированные возможности, позволяющие остановить его. Возможно ещё перезапустить/перезагрузить конфиги. Серверное приложение _фактически_ не работает вечно, оно регулярно перезапускается после изменения конфигурации или наложения патчей безопасности.
> У вас какая-то другая точка зрения как это реализовать?
Я могу предложить штуки три альтернативы. 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...
> Реальное серверное приложение имеет документированные возможности, позволяющие остановить его.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. Это будет работать, но так делать не надо.
с чего вы взяли, что выход из "вечного цикла" возможен только лишь при нештатных ситуациях? Вы код автора открывали? Выше указал даже номера строк.
>но для каждой функции описывать структуру с возвращаемым типом -- это всё же бред
О да, это прям как - всё есть класс )
>Я не очень понимаю
Ну и я не понимаю, зачем нужны вообще всякие ЯП, когда есть КОП процессора :)
> 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++ показал, что гумно это не только по каким-то замудрёным теоретическим причинам, типа потому что нарушение принципов структурного программирования, но и по вполне практическим.
> Ну и я не понимаю, зачем нужны вообще всякие ЯП, когда есть
> КОП процессора :)КОП какого процессора?
>При чём здесь 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++ показал, что гумно это не только по каким-то замудрёным теоретическим причинам, типа потому что нарушение принципов структурного программирования, но и по вполне практическим.
мне было бы очень интересно послушать, что придумали бы вы на месте Страуструпа (серьезно). Как можно разрешить данную проблему?
>КОП какого процессора?
Того, который собираетесь использовать. Машина Тьюринга одна (ну есть еще машина Поста и т.д.), архитектура того же процессора - одна (Фон Неймановская).
>>При чём здесь 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'ке погонять.
> Нет, не без разницы. server->accept, вероятно, проводит не только accept на сокете,
> но ещё и "обмен приветствиями" с клиентом, что можно порождать новые
> классы ошибок.все порождаемые accept "классы" ошибок - описаны, не определенных ошибок нет!
> То есть код, который удаляется сразу после написания? :DЛучше сразу пулю в висок.
> Знаешь, чем дольше я наблюдаю за людьми цитирующими Гёделя, тем больше я
> прихожу к выводу, что все эти цитаты исключительно от необразованности. Чтобы
> цитировать Гёделя, необходимо не понимать Гёделя.ок, не образован.
> О, Бога ты тоже не зря упомянул. Вижу догматизм в тебе я,
> и всуе Бога упоминание к лицу тебе.Догма - аксиома, вспоминаем значение слова.
> Тут ты самым позорным образом путаешь тёплое с мягким. Русский язык предоставляет
> возможность выражаться красиво и точно. То что он при этом предоставляет
> философское матерное подмножество, позволяющее выражаться грязно и неточно -- это другой
> вопрос.В смысле "философское матерное" подмножество? И дайте определение "грязно" и "неточно". Тот же goto это ПНХ.
> Control flow -- это "течение управления", это то как исполнитель программы движется
> по коду. Если твои словари не объясняют тебе этого, то это
> много говорит нам о никудышнем качестве твоих словарей, и ничего не
> сообщает о control flow, потому что мы знаем больше тебя."движется" - движение есть последовательность шагов, и как указал прежде - детерминированность.
> Вот это проявление того самого догматизма.
читаем выше про догму.
> Дитятко, если я упоминаю людей, агитирующих за удаление goto из языка, это
> не значит, что я сам поддерживаю удаление goto из языка. Так
> что не надо мне тут нотаций читать, они совершенно не к
> месту.а к какому месту упоминание тех самых людей? и тем более которых не поддерживаете. Определитесь уже, я же говорил мне ваши мысли интересней, а не чужие с которыми вы не согласны.
> Кто тебе сказал, что нет зависимости? Это ещё один пример "смотрю в
> книгу вижу фигу".ну приведите пример зависимости.
> Код выше. Цикл, из которого штатный выход выполняется через throw/catch.try/catch - не штатный выход.
> Если тебе хочется провести аналогию между C++ и лентой в машине Тьюринга,
> и посмотреть во что превратиться локальность, то тебе надо говорить о
> локальности символов на ленте.каждый символ на ленте ограничен своей ячейкой, о какой локальности идёт речь?
> Я давал выше ссылку на статью обсуждающую throw/catch и предлагающую альтернативы. В
> той статье есть аж три ссылки с возможными реализациями Either. Пока
> я искал ту статью я нашёл ещё две реализации Result на
> C++, которые по-сути то же самое, только с другим названием. Гугли.повторюсь "мне было бы очень интересно послушать, что придумали бы ВЫ на месте Страуструпа (серьезно)."
> Машина Тьюринга не существует, глупыш. Машина Тьюринга -- целиком и полностью выдумка.
> Это миф. Сказка.дальше можно не читать!
> try/catch - не штатный выход.ДА ЛАДНО! НЕ МОЖЕТ БЫТЬ!
> каждый символ на ленте ограничен своей ячейкой, о какой локальности идёт речь?
Знаешь, мне надоело объяснять. Думай сам. Если тебе хочется, чтобы я за тебя думал, то мы можем обсудить расценки.
> повторюсь "мне было бы очень интересно послушать, что придумали бы ВЫ на
> месте Страуструпа (серьезно)."В смысле? Ты хочешь чтобы я всё написанное записал бы в виде аудио, чтобы ты мог послушать? (Серьёзно?)
с пруфами лучше, вот ссылка на 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;
#endifwhile (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.
}При любой нештатной ситуации, цикл отрубится.
https://github.com/dmitigr/fcgi/blob/master/lib/dmitigr/fcgi...Строка 153, и смотрим при каких условиях прервется ваш цикл.
Что-то я не понимаю. Почему какая-то поделка ноунейма выкладывается на opennet? Проплачено или что?
> Что-то я не понимаю. Почему какая-то поделка ноунейма выкладывается на opennet? Проплачено
> или что?Конечно.
"Оригинальные новостные статьи"(тм) оплачены щедрыми донорами.
Сбор донатов на опеннете -- видел, да?
Так вон они, ниже в конце страницы :)
#>>Сбор донатов на опеннете -- видел, да?
> Так вон они, ниже в конце страницы :)Эти - не те. Не видел, значит. Окэ.
>Почему какая-то поделка ноунейма выкладывается на opennet?Потому, что open source?
аффтар сам и выкладывает, пиарится
точнее - позорится
Автор, начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n что ли (это я мягко так намекаю про "нужность" дефайнов с crlf).
Да и вообще код действительно выглядит как поделка, а использование С++17 в описании - лишь как маркетинговая уловка.
просто обезьяныш не умеет не обмазываться свеженьким, и c++17 в описании означает не какие-то там достоинства кода, а просто то, что ничем кроме пре-альфа-версии gcc99 это не собирается.
> Автор, начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n
> что ли (это я мягко так намекаю про "нужность" дефайнов с
> crlf).
> Да и вообще код действительно выглядит как поделка, а использование С++17 в
> описании - лишь как маркетинговая уловка.Этими дефайнами автор хочет, вероятно, привести код в соответствии протоколу HTTP, в котором перевод строки строго определён как "\r\n". Так что мат. часть, вероятно, надо учить как раз Вам.
Что подвигло Тима Бернерса-Ли выбрать для перевода строки \r\n, он же ползовался NIX-like ОС?
Я могу предположить. Использование "\r\n" в качестве разделителя строк протокола позволяет в одну строку протокола впихнуть многострочный файл со "\n" в качестве разделителя строк. Но это лишь предположение, реально я не знаю как дело было, просто ты задал вопрос, я задумался над этим, и мне пришёл в голову такой вот возможный ответ.
> Что подвигло Тима Бернерса-Ли выбрать для перевода строки \r\n, он же ползовался NIX-like ОС?А он и не выбирал. Он просто передрал RFC822.
Ну то есть не передрал, а сослался, конечно.
https://tools.ietf.org/html/rfc2068#section-4.1
Совершенно верно. operator<< - это оператор форматированного вывода. Вызов ostream << "\n" записывает в поток "\r\n" в Windows и "\n" в Unix. Протокол HTTP предписывает использование "\r\n" в качестве разделительной последовательности.
> автор хочет, вероятно, привести код в соответствии протоколу HTTP, в котором перевод строки строго определён как "\r\n". Так что мат. часть, вероятно, надо учить как раз Вам.Матчасть учить нужно тому, кто не знает про существование std::ios_base::openmode binary, когда ему нужно выводить данные в поток без преобразования символов под конкретную ОС.
> начни с чтения вот этого 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".
> зависимость перевода строки от платформынет.
В смысле? Он не выводит "\r\n" в венде? А зачем тогда он нужен такой? Ну вот вообще зачем было заморачиваться добавлять в библиотеку endl, если "\n" нагляднее?
В одном клике от твоей ссылки: 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().
> В одном клике от твоей ссылки: 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 в библиотеку?
> Что такое os.widen? Что он там расширяет? Не расширяет ли он заодно '\n' до \r\n, когда нужно?Он — нет. Он только кодировки преобразует, если надо (в UTF-16LE, например, мало ли). А возврат каретки и без него добавляется в ostream. Я хз, чё они курили, но просто вывести \n на винде ещё постараться надо.
> Автор, начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n что лиЗдесь автор. Мне не нужно это читать.
> (это я мягко так намекаю про "нужность" дефайнов с crlf).
Эти дефайны обеспечивают кроссплатформенность кода.
> Да и вообще код действительно выглядит как поделка, а использование С++17 в описании - лишь как маркетинговая уловка.
Это именно поделка, которой я любезно поделился с сообществом. Кому не нравится, тот просто обходит стороной.
О круть, сам автор тут)Хотелось бы одно замечание сделать
"namespace dmitigr"
простите, но что за "неймдроппинг" такой? как то не серьезно.
Спасибо за комментарий. Странные у Вас вопросы. Резервирование пространства имён для проектов одного автора или компании - обычная практика. Я зарезервировал пространство имён dmitigr для своих проектов. А, например, Niels Lohmann, выбрал пространство имён nlohmann для своих проектов, например namespace nlohmann::json.
Указатели все разыменовали? За границы буферов не повыходили? Или как обычно?
> Указатели все разыменовали? За границы буферов не повыходили? Или как обычно?Надо больше замыканий, монадов, строгой типизации и W^X на опенне ^W Microsoft Github-е!
Замыканий лучше коротких.
> Замыканий лучше коротких.Вот про размер не надо.
Разыменовыватели буферов и разграничители указаетелей обидятся же.
Не стоит беспокоится. Все разыменовали и за границы не повыходили. Будут проблемы - обращайтесь. Как обычно.
Используем стд:стринг, автоуказатели и горя не знаем.
А ты как перебиваешься, мир небось замирает, как в матрице у Нео. У него тоже ГЦ неоптимизированный был
Я таки ничего не знаю за автора этого кода, но на своем персональном сайте он называет себя исключительно "мы". Несколько настораживает...
> Я таки ничего не знаю за автора этого кода, но на своем
> персональном сайте он называет себя исключительно "мы". Несколько настораживает...Может, его кот по клавиатуре прогуливался. Мы B-P ж не знаем.
Предлагаю скинуться и выслать ему пачку декариса.
С официального сайта: "Нам нравится творить".
Вот такие натворят, а потом другим расхлёбывать приходится. За счёт бизнеса (которая платит дважды или даже трижды).
неюзабельно
уровня студента
давайте побольше ваших сладких булочек
В каком месте там неюзабельно и в каком месте уровень студента. А то это уже не первый комментарий подобный.
Это будет иметь отношение к mod_fcgid для Apache?
Нет. Никакого отношения к mod_fcgid обсуждаемая библиотека не имеет. Вы можете использовать mod_proxy_fcgi для проксирования HTTP-запросов приложению на базе dmitigr_fcgi.
Вот взъелись вы на дядьку. А он может работу ищет. Сейчас на каждом собеседовании второй вопрос это "есть ли у вас открытые проекты на гитхабе". Поэтому надо выложить хоть что-нибудь, чтобы иметь какой-то вес на собесе.
Это классика. 5 стадий принятия неизбежного: отрицание, гнев, торг, депрессия, принятие. Сейчас где-то фаза 1 или 2. Потом полегчает :-)
Спасибо за беспокойство! Работу я не ищу.
> 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__)}; \
} \
}
Кто-то может объяснить смысл?
Может быть какая-то либа-зависимость не установлена?
> Может быть какая-то либа-зависимость не установлена?Если я нашёл определение, значит нашёл и либу (того же автора).
Вопрос по сементике самого макроса.
> Вопрос по сементике самого макроса.Что конкретно Вам не ясно?
>> Вопрос по сементике самого макроса.
> Что конкретно Вам не ясно?Не ясно, зачем ассерт бросает исключение, которое:
а) из названия не очевидно;
б) может быть по недоразумению проигнорировано.Плюс к тому, существует вариант 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)) }
То есть: либо автор не стал менять название, постепенно модернизируя давно написанное, либо есть скрытый от малознакомых с новыми веяниями С++ (т.е. от меня) смысл.Ну и было интересно, кто что скажет из знатоков, коих тут в избытке.
Здесь автор.> Не ясно, зачем ассерт бросает исключение
Я используют DMITIGR_ASSERT() вместо стандартного assert() почти везде из-за того, что обычный assert() слишком груб и по умолчанию приводит к завершению программы. DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно. (Мне очевидно, что надо это задокументировать.)
> а) из названия не очевидно;
Спасибо за замечание. Я задокументирую этот момент!
> б) может быть по недоразумению проигнорировано.
По недоразумению может быть всё, что угодно. std::logic_error игнорировать не стоит. Это признак бага в программе или в библиотеках, от которых она зависит.
>Я используют DMITIGR_ASSERT() вместо стандартного assert()Кто тебе мешает использовать нормальные имена?
>слишком груб и по умолчанию приводит к завершению программы.
Это семантика асерта.
>DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно.
https://github.com/dmitigr/common/blob/b582b4daf674eed5df1d1...
Что это за нелепое говно? Ты вообще понимаешь почему assert макрос? Только для LINE и т.п. Если ты что-то там вещаешь про "модный С++" и пытаешься(нелепо) использовать увиденные где-то трюки(constexpr/constexpr if), то на них логика и должна быть построена. Эта же клоунада - просто клоунада нелепая. Зачем ты превратил макрос в переменную, что-бы потом использовать нахрен ненужный так constexpr if?
>>Я используют 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, что не всегда удобно при разборе кода.
>constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef.Полный бред. Я там объяснял почему.
>IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода.
Причин гениальней это я не слышал. Т.е. constexpr if только для того, чтобы захакать ide? Да, сильно. К тому же, чем это неудобно я так и не понял.
>>constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef.
> Полный бред. Я там объяснял почему.Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент.
>>IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода.
> Причин гениальней это я не слышал. Т.е. constexpr if только для того,
> чтобы захакать ide? Да, сильно. К тому же, чем это неудобно
> я так и не понял.Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...
>Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент.Технический. Твоя обязанность обосновать. Ты не обосновал, а поиграл в клоуна. Именно это является бредом.
>Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...
И, что ты этим показал? Ну кроме того, что ты привык жрать птушное говно.
>>Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент.
> Технический. Твоя обязанность обосновать. Ты не обосновал, а поиграл в клоуна. Именно
> это является бредом.Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси.
>>Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...
> И, что ты этим показал? Ну кроме того, что ты привык жрать
> птушное говно.Это была Чорная Магия. Заклинание 1го уровня "зеркало". Всего лишь.
>Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси.Клоун, мне без разницы на то кто ты. Ты для меня не отличаешься от любого другого клоуна в интернете. Ты пыль. Твоя задача - либо смешить меня жалкими потугами что-то мне ответить, либо обделаться. Ты выбрал второе, и я даже жалких потуг не увидел.
>Это была Чорная Магия. Заклинание 1го уровня "зеркало". Всего лишь.
Опять нырнул в дерьмо.
>>Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси.
> Клоун, мне без разницы на то кто ты.Знаю. Ты ошибся адресатом, что лишает персонализированные обращения смысла, но для тебя это ничего не меняет. Плоды фантазии безусловно верны для бредящего.
> Опять нырнул в дерьмо.
Смотри, не задохнись. Зачем ты вообще это делаешь?
> Здесь автор.
>> Не ясно, зачем ассерт бросает исключение
> Я используют 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.
Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы. То есть ошибки входных данных. Если же срабатывают ассерты, то запускать программу немножко рано -- она даже собрана на для релиза.
> А зачем продолжать её исполнение?Здесь больше интересен вопрос: как по-мягче завершить её выполнение? Меня не устраивает заверешние через 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++.
>> А зачем продолжать её исполнение?
> Здесь больше интересен вопрос: как по-мягче завершить её выполнение? Меня не устраивает
> заверешние через 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 -- надо постараться.
> Наверное, прежде всего для этого необходимо обеспечить 100% гарантии вызова обработчика исключений, ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии.Обработчики исключений, которые пересекают границы библиотек, определяются в приложениях.
> ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии.
О каком неконсистентном состоятии речь?
> При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :)
Он называется DMITIGR_ASSERT(), а не ASSERT() или Assert(). Поэтому судить о семантике следует либо из документации, либо из определения.
> __builtin_trap() - ошибка физическая (на x86 транслируется в UD2). SIGILL логическая. Тоже генерируют исключение, которое можно попробовать поймать, но перепутать его с подмножеством ошибок std::logic_error -- надо постараться.
Не совсем понял к чему это, но исключения std::logic_error ловятся стандартным образом.
>> При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :)
> Он называется DMITIGR_ASSERT(), а не ASSERT() или Assert(). Поэтому судить о семантике
> следует либо из документации, либо из определения.Следует? Автору виднее. Автор может поступать, как считает нужным. Сам.
Следует. С чего вдруг некий DMITIGR_ASSERT() должен повторять семантику стандартного assert()? Наличие слова "ASSERT" в названии к этому не обязывает.Мне не понятно, зачем вообще Вам этот макрос? Это деталь реализации. Пользователям библиотеки она совершенно не нужна. Если Вы собираетесь поучаствовать в разработке, то Вы уже знаете что это за макрос, благо его определение занимает 5 строчек. Спасибо за дискуссию!
> Следует. С чего вдруг некий DMITIGR_ASSERT() должен повторять семантику стандартного assert()?"Должен" не то слово. Есть ожидания пользователя, читателя кода. Если они расходится положением дел, возможны варианты (принять/не принять).
> Мне не понятно, зачем вообще Вам этот макрос?
Интерес представляет в первую очередь ход мыслей автора. Если глаз цепляется, значит такое наверняка повстречается где-то ещё. Чем больше задаю таких глупых вопросов, тем проще потом сориентироваться в новом коде. Документация не всегда в наличии, как и исходники. Благодарю за разъяснения.
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_Аффтару нимб не жмёт?
FastCGI настолько простой протокол что только ленивый студент не реализовывал его на своем любимом языке
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.
Автор, ну ты понел.
пишут что нужно `common` имени дмитрия ингишина иметь:
https://github.com/dmitigr/fcgi/blob/master/README.md#depend...
То есть он даже поиск библиотеки в cmake не осилил? Молодец какой. Дальше смотреть не вижу смысла.
Кто-то не осилил прочитать документацию. Дальше смотреть нет смысла.В действительности, всё что требуется, это установить библиотеку dmitigr_common. Всё остальное CMake сделает автоматически.
Установить куда? А если я её в нестандартный префикс хочу, чтобы систему не поганить? CMake должен делать автоматически не «всё остальное», но и поиск библиотеки тоже. Если её нет — вывести внятное сообщение об ошибке. А тут конфигурация типа прошла успешно, а оказывается — зависимостей не хватает!
Спасибо за отзыв. 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.cmakeAdd 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)
Действительно, сообщение есть, я его не заметил. Но это всего лишь warning, статус завершения 0, Makefile создался, в конце:Using library
-- Configuring done
-- Generating done
-- Build files have been written to: /home/anon/fcgi/buildПотому выше по логу и не смотрел. Должно быть завершение с ошибкой, если зависимость обязательная.
Спасибо, исправил! Эта регрессия появилась из-за относительно давнего рефакторинга. Я её и не замечал.PS. Ведь можно же как-то проще сообщать о недочётах. А то чуть что, так сразу "автор неосилил". Не этично.
> PS. Ведь можно же как-то проще сообщать о недочётах. А то чуть
> что, так сразу "автор неосилил". Не этично.Это опенсорс! Никто никому ничего не должен™.
> Это опенсорс! Никто никому ничего не должен™.Хм. А какое Вы имеете отношение к open source? Разве Вы что-то сотворили?
You must be new here.
Список новостей:
- Microsoft открыл код библиотеки векторного поиска, используемой в Bing
- Дима Игришин сделал git push
- Фонд свободного ПО сертифицировал звуковые карты и WiFi-адаптеры ThinkPenguin
Ну и норм
Судя по коду это fcgi, а не fastcgi. какой смысл тогда?
Это реализация FastCGI. FCGI - это сокращение FastCGI.
dmitigr, бенчмарки вашей реализации есть для сравнения?
Бенчмарков нет. Я сравнивал с libfcgi. dmitigr_fcgi быстрее где-то на 15-20%. Я знаю ещё несколько мест в своей реализации для оптимизации и прироста производительности. В скором времени улучшу.
> Бенчмарков нет. Я сравнивал с libfcgi. dmitigr_fcgi быстрее где-то на 15-20%. Я
> знаю ещё несколько мест в своей реализации для оптимизации и прироста
> производительности. В скором времени улучшу.интересно. с активным по сей день с библиотекой https://github.com/eddic/fastcgipp (C++14) попробуйте произвести бенчмарки, будет очень интересно. в будущем надеюсь в проекте бенчмарк отчеты появятся.
Заявление ничем не подкрепленное?
Ну ок.
Библиотека dmitigr_fcgi реализована в соответствии со спецификацией FastCGI. См. http://www.mit.edu/afs.new/sipb/user/yandros/doc/specs/fcgi-...FCGI - это сокращённое название FastCGI. Apache mod_fcgi или mod_fastcgi не имеют никакого отношения к моей библиотеке.
Многие тут комментаторы от Бога так и не понимают в чем изюминка этой реализации FastCGI, дело в " написанная на современном C++17" - "The FastCGI implementation on modern C++".Делая выводы можно сказать что она как алтернативная реализация по спецификации FastCGI придаст прирост в производительности, легкости и т.д., что позволяет дать современные последние версии компиляторы c поддержкой C++17 (ведь язык программирования C++ тоже не стоит на месте и совершенствуется)
P.S: кстати, если кто-то будет искать закрытый сайт FastCGI, можете посмотреть в архиве: https://fastcgi-archives.github.io/
> Многие тут комментаторы от Бога так и не понимают в чем изюминкаМногие комментаторы здесь делают сознательные усилия, чтобы не понимать. Всё комментирование здесь сводится к специальной олимпиаде на тему, кто самым возмутительным образом не поймёт, что написано.
> Многие комментаторы здесь делают сознательные усилия, чтобы не понимать. Всё комментирование
> здесь сводится к специальной олимпиаде на тему, кто самым возмутительным образом
> не поймёт, что написано.особенно (A|O)нонимы :)
> как алтернативная реализация спецификации FastCGIКхммм, спецификации? вы серьезно? Альтернативная реализация ---> по <--- спецификации FastCGI!
> Кхммм, спецификации? вы серьезно? Альтернативная реализация ---> по <--- спецификации
> FastCGI!да, верно, имелось что это не новая спецификация FastCGI, а имплементация его
> Делая выводы можно сказать что она как алтернативная реализация спецификации FastCGI придаст прирост в производительности, легкости и т.д.Из чего и каким образом можно сделать такие выводы?
> усоверешенствовыется
Ты б свой русский посвершенствовывал, что ли.
>> усоверешенствовыется
> Ты б свой русский посвершенствовывал, что ли.после чтения толкового словаря по русскому языку, исправлено. старую информацию смотрите, нажмите F5 :)
Бывает, когда в мыслях проговариваешь, а в комментарии думаешь что написал, да, да, нажимаем сразу отправить потом только видим ошибку :)
> on modern C++Писать по-английски – это вообще-то не слова по словарю с вашего языка переводить.
>>>> Зачем ты, клоун, пытаешься защищать свою жопу
>>> Веришь ли, но в природе это норма. Пока мы жили на деревьях,
>>> для таковой защиты имелся даже специальный орган -- хвост. Потом появились
>>> разум, этикет, одежда.
>> И когда же вы жили на деревьях?
> До момента пока не изрёк Господь Бог "сотворим человека по образу Нашему
> и по подобию Нашему".Креационизм ничем не хуже утверждений, что хвост предки человеков потеряли из-за появления разума, этикета и одежды.
Кстати, уже давно считается, что у человеков и бибизьян был общий предок. Так же известно, что далеко не все бибизьяны живут на деревьях.
Строение человеческой стопы и отсутсвие хвоста, как бы, намекают немного сведующим в биологии, где именно жили предки человеков.
>Делая выводы можно сказать что она как алтернативная реализация по спецификации FastCGI придаст прирост в производительности, легкости и т.д., что позволяет дать современные последние версии компиляторы c поддержкой C++17 (ведь язык программирования C++ тоже не стоит на месте и совершенствуется)Трудно представить, какой приницпиальный выигрыш в производительности может быть у реализации FastCGI на С++ по сравнению с С, не говоря у же о С++17 по сравнению со старым С++. Там же простой бинарный протокол, который парсится обычными сишными структурами
cppcms же есть
Зачем есть же libevent с HTTP поддержкой
Во-первых, топик про FastCGI. Во-вторых, где libevent, а где cppcms.. В последней есть всё для создания полноценного web-бэкенда (транспорт, маршрутизация запросов на исполняющий код, пулы рабочих потоков, сессии и сопутствующие шифрование и hmac-и, json, журналирование и проч.), и оно уже на плюсах и используется в проде.
Непонятно откуда столько негатива в коментах. Люди, вы если с чем-то несогласны, пишите аргументировано. Давайте уже перестанем сеять среди нашего общества негатив.Советую к прочтению:
en: http://paulgraham.com/disagree.html
ru: https://web.archive.org/web/20120505004501/http://translated.../
+1
наследие СССР :)
чушь. при СССР технари к технарям оч.хорошо относились. почитайте сообщения на форумах/эхах 90х годов (это как раз поколение выросшее в СССР) - все оч вежливо, никакой ругани, ехиндичиства и т.д.те, о ком вы говорите совсем другое поколение.
> те, о ком вы говорите совсем другое поколение.ну я как раз имел в виду не технарей, которые в годы СССР работали, а последствия распада СССР, приходом демократии, и приходом диванных критиков :)
Поколение Пепси
> Поколение Пепситочно +1
А сейчас смузи.
> Советую к прочтению:
> en: http://paulgraham.com/disagree.html
> ru: https://web.archive.org/web/20120505004501/http://translated...Спасибо за статью Полу, а Вам -- за ссылку!
Народ, вы чего ? Человек написал библиотеку, выложил бесплатно, никого использовать её не заставляет... Где здесь повод исходить говном ?
Это массовый психоз какой-то :-(
Да какой массовый? Парочка типичных персонажей изображают толпу.
Утешься прекрасным:
Лично мне просто непонятно почему это в новостях на опеннет. Разве это какая-то значимая для 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 за пять.
забота о пользователе зашкаливает...
>> 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)
3.17 это самая последняя версия cmake на офф.сайте (3.17.2)
её только вручную ставить
чё без cmake никак чтоли не поставить это чудо инженерной мысли?
а это чё:
>> /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
