Вася Уткинdbpatchпропущено...

Это все слухи. Использовать для управляющей системы Linux, который ни разу не real time - как минимум странно, при том, что есть 100500 реализаций RTOS, в т.ч. очень хороших.

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

в этом плане для меня выбор Pure C был как раз этим и продиктован - даже если мне
захочется вывалить нечто, то сама среда мне не позволит, плюс статический анализатор еще по голове надает.
Если ты предлагаешь оценивать качество кода по вероятности нет-нет и написать new/delete или malloc/calloc/free , то ты живешь прям в яме с говнокодом А учитывая, что твой выбор этим и был продиктован, то это уже фетишь.
Ну и естественно в Space X все врут :)

чувак, у тебя явные проблемы с формальной логикой. если я не пишу явные формальные правила против говнокода, то я живу в яме с говнокодом? атас, приплыли. если у меня так все базнадежно, то зачем я их пишу? чтоб увидеть 100500 сообщений в статиканализаторе и просто подавить этот warning?

не писать new/delete - я говорил вовсе не об этом, это довольно простое правило, которое можно вписать в статический анализатор и он тебя будет каждый раз тыкать в это теплое мягкое.

в современном C++ есть штуки куда более страшные, чем new/delete, которые так и тянется рука заюзать, ибо очень дешево же - и случаи бездумных объявлений векторов в куче вместо статических массивов на стеке - это лишь самая вершина айсберга.

самая мякотка в перегруженных операторах, вот там полный жескач - их и человек порой не всегда раскурит, а научить статик аналайзер понимать, что это оператор не сложения, а вызов форматирования диска C - это никакие современные AI не могут

а написать статик аналайзер на ваши просто адские темплейты с их SFINAE ? да ну... в сад, сад, сад

White Owldbpatchвот смотрю я на твой код и начинаю туда-сюда прыгать глазами - может вон та хвунция выздвать ексепшин или нет, а что если, а что не если, а может ли write_to_log че-то бросить или нет.Когда пишешь с исключениями - автоматически думаешь: "это функция, значит она может бросить исключение". Никаких вопросов "может или не может бросить" просто не возникает.
И что? каждый вызов метода оборачивать в свой собственный блок try {}? да ну да, щас, кто так делает?

и да - никто там ни о чем не думает, не надо врать самому себе. все тестируют исключительно "беспроблемное" поведение, никто сейчас не пытается задуматься даже на такие случаи, как out-of-memory или out-of-disk space, зачем?

и ладно бы - у всех бы стояли обертки над malloc()/free()/write(), которые бы не бросали в юзера неожиданный Out exception/errno, а просто бы переводили приложение в suspend state пока админ-юзер не прочистит всякое, так нет - почти все просто аварийно и непредсказуемо - и нетестировано (!) фейлятся, с корраптом и потерей данных и прочим подобным разным - никто тестов на аварийное завершение ведь не делает, а зачем?

так что не надо ляля, думают они. щазззз...


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

White OwlЭто серьезно помогает не терять беглые исключения. С другой стороны, если какая-то функция может теоретически бросить исключение, но ты знаешь что в этом конкретном случае исключения быть не может (или его просто можно проигнорировать безопасно для алгоритма), то в Java это "игнорирование исключения" опять таки надо явно прописывать, а в С++ просто "забываешь" про него.

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

язык, который изначально стимулирует писать только неверифицируемый код (говнокод), и - это какое-то просто издевательство над человечеством

Siemargldbpatch,

Не вижу разницы между возвратом набора результкодов и выбросом фиксированного набора типов исключений.
И то и то надо обрабатывать.

См. выше пример вызова макроса VERIFY_OS() - вся обработка сидит вообще в одной строке и только там.

для более кустистых случаев - в случае кода возврата обработка просто гарантированно не выходит за пределы вызываемой функции (если конечно правильно писать обработчики), а необработанный ексепшин начинает лететь наверх, и куда и как он там прилетит - а вот полный ХЗ - и что хуже - обычно никто не делает даже простейшее тестирование покрытием кода.

говоря проще - меня статический анализатор ткнет носом в то, что я не включил вот такое-то новое значение кода возврата в блоки switch(), иди дописывай, а в случае exception он не имеет такой информации - может это не мой косяк а такой вот хитрый план - бросать это недоразумение наверх, дескать пусть юзер его сам почитает.

так понятнее? привинтить статик аналайзер на исключения не есть возможно в принципе

SiemarglВот только в С++ нет явно прописанного fn() throws AA, BB, XUXU или nothrows - это появилось в более поздних языках.

эту штуку выпилили в Java (судя по постам на хабре), ибо неработоспособно это все.

SiemarglИтого, это на верифицирование и надежность не влияет.

походу у тебя под вечер мысли туго вертятся, раз такие выводы делаешь

AdxКак это не могут? try ... код ... catch. Попадание в блок catch - неуспешное завершение. То же само, что и с кодами, только там нужно каждую строчку обернуть в макрос, который делает то же самое, что и блок catch.

Если важна для логики программы причина ошибки - обрабатывай типы и коды ошибок, если нет (что обычно о требуется) - обрабатывай единообразно.



Какие-то вы право странные, прямо.

Если в случае VERIFY_OS(fopen()) - я в этом макросе имею строго определенный и документированный блок кодов возврата какой-то строго одной системной функции, и не ожидаю там всякой левой хрени, которая не относится к fopen(), то в случае исключительной ситуации на типовой ООП хрени, особенно на чуть более высоких уровнях - я вообще не уверен в том, кто и что мне может прислать, особенно в новых редакциях кода или библиотек.

Это может сделать уже к примеру write() или какой блок логгирования, при том, что я изначально этого эффекта там не ожидал ни разу.

О какой блин уверенности тут может идти речь? Мне нужно гарантированно не выпускать исключительные ситуации дальше той функции, где они возникают, но в случае типового ООП подхода (пробрасывай наверх все то, что не смог сам) - это уже не работает, так просто не принято делать, принято все необработанное бросать вышестоящим товарищам, авось они там разберутся.

И это и есть концептуальный "сдвиг по фазе". Это все равно что сантехник, который не смог закрутить кран - сбрасывал бы свои проблемы в виде аварийного потока воды на электрика, просто потому что электрик позвал этого сантехника выключить воду.

Adxdbpatchименно потому писать на C++ промышленно отказоустойчивый код в принципе не есть возможно


... но вполне этим занимаются. Просто нужно понимать, где исключения можно использовать, а где нет. В коде, где идут подряд операторы, проверяющие код, пишущие в лог, и осуществляющие возврат - без проблем. Там где нужно обработать код по схеме конечных автоматов - не подходят, впрочем, как и подобные макросы.
В общем - Вы не любите кошек? Вы просто не умеете их готовить!

Ой, я вас умоляю. Нет проблем на написании в лог. Вы попробуйте там создать проблему, нехватку места на диске или памяти, и попробуйте посмотреть к чему это в итоге приведет.

И что значит не умеете их готовить? Их вообще никто не умеет готовить, ибо сама концепция исключительных ситуаций - она изначально концептуально неверна.

Идея делать longjmp в неопределенные места при необработанных кодах возврата у любого C программиста вызовет лишь покручивание пальцем у виска, но для ООП программиста это полный нормуль, и никто не задумывается, что это же просто невероятная глупость.

Алексей КWhite OwlДругое дело что при этом можно забыть сделать перехват...Ну в прикладном коде иногда перехватываешь исключения, про которые точно знаешь. Остальные уходят "наверх". И где-то "совсем сверху", в системном коде, есть место, в котором перехватываются ВСЕ исключения, с целью логирования.

в том-то и проблема, что возникшая исключительная (аварийная) ситуация, прямо как сошедший с рельсов поезд - начинает мчаться по блокам кода, дескать давайте, сделайте там очистки ресурсов, закрытие файлов и что там еще нужно сделать.

при том что нет никакой гарантии, что вообще что-то сейчас удастся исправить, и что это "исправление" хоть как-то когда-то тестировали.

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

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

и это и есть фундаментальная концептуальная дыра. дырища. в головах