>>При чём здесь 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'ке погонять.
