The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Реализация FastCGI на современном C++, opennews (??), 17-Май-19, (0) [смотреть все]

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


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ообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру