"обработка исключений" vs "обработка кодов возврата"

[Majestio]

Qraizer, это не самое плохое! Хуже, когда работаешь в режиме "динамического ТЗ". У меня был такой опыт. Делал проект в районе 3-х лет, когда (по моим оценкам) он должен был исполнится в 3-4 месяца. Заказчик - "государство". Какие нахер правила, стандарты и прочее?! Приходит "очередной" директор, и всё начинается по-новой. Так что твой MISRA по сравнению ... самый красивый кросавчег!

[Qraizer]

Ну, меняющиеся ТЗ ничто не победит. Кроме денег. Новый директор, новые правила — новый ценник

[D_KEY]

Цитата Majestio @ 13.12.24, 15:46

Цитата D_KEY @ 11.12.24, 14:42

Я могу понять, зачем так делать для vector. Но для нового класса, еще и предназначенного для ошибок, я бы спрятал беспроверочную версию за отдельным методом (желательно с уродским названием).

У меня есть предположение ...

С++ никогда не позиционировался как язык программирования с "исключительной поддержкой безопасности". Даже вспомнить спичи про его предшественника Си - про него часто говорили мол это "высокоуровневый ассемблер". Вывод? Простой. С++ предоставляет сперва самые быстрые варианты обработки. И только потом "помогает" в случае х3 чего контролить процесс исполнения. Простой пример. Ты явно задаешь вектор из 16Гб элементов, явно и строго! Зачем тебе в этом случае контролить счётчик индексов, чтобы он не вышел за диапазоны? Для этого и нужны методы без проверок, они сокращают время исполнения.

Но тебе ни кто не запрещает влепить операторы с контролем. Только в продакшене это кому-нить будет нужно?!

Для вектора мне понятно, а вот для expected - нет. Мы вводим класс для типобезопасной обработки ошибки и он тут же нам подкидывает undefined behaviour на самой распространенной операции, которые незнающие люди будут использовать по умолчанию. Это в каком-то смысле обесценивает вообще наличие std::expected.

Добавлено 14.12.24, 00:17

Цитата Majestio @ 13.12.24, 16:16

Везде во всех либах С++ "стремится" к производительности, и тут внезапно ДиКей запустил "желалку"! Мол, а "давайте все проверять по умолчанию!". И я тут против. Не для такого как "он" Си писались, "перестраховщик"!

Ты мои слова перевираешь зачем-то.

Во-первых, я согласен с политикой std::vector. Во-вторых, я пояснил, почему считаю это плохим дизайном именно для std:: expected. Лучше бы они вообще тогда не делали operator* и ->
И именно отдельные методы с проверкой и без проверки, с нормальными именами.

Добавлено 14.12.24, 00:18
Завязывай с переходом на личности. Это тематика таки

Добавлено 14.12.24, 00:23
В общем, Expected из folly (либа от Facebook), выглядит приятнее. Ну и там чувствуется рука Александреску, который идею expected и продвигал.

[Majestio]

Цитата D_KEY @ 14.12.24, 00:12

Для вектора мне понятно, а вот для expected - нет. Мы вводим класс для типобезопасной обработки ошибки

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

Цитата D_KEY @ 14.12.24, 00:12

Ты мои слова перевираешь зачем-то.

А вот и нет А кто выше писал о "типобезопасности"? Это по-любому влечет за собой проверки, или на стадии компиляции, или в рантайме, без разницы!

Цитата D_KEY @ 14.12.24, 00:12

Завязывай с переходом на личности. Это тематика таки

Какие мы нежные и чувствительные Но ок, за "перестраховщика" - прости, я не со зла!

[D_KEY]

Цитата Majestio @ 14.12.24, 03:07

Новый способ обработки есть, типобезопасности обработки ошибок нет. И всего-то.

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

Постепенно, думаю, будет распространенной практикой отказ от разыменования (ну разве что с разрешением его использовать немедленно после проверки в одном блоке) и использование других методов (value, value_or, and_then, or_else, transform и пр.)

Добавлено 14.12.24, 09:29
Вот цитата из предложения в стандарт (из мотивационной части):

Цитата

Error visibility: It takes the best of the exception and error code. It’s visible because the return type is expected<T, E> and users cannot ignore the error case if they want to retrieve the contained value.

А вот нет, могут. Это у Александреску и folly нельзя, а в std можно проигнорировать, просто ставим -> или * и получаем UB.

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

Сообщение отредактировано: D_KEY - 14.12.24, 09:29

[Majestio]

Цитата Majestio @ 14.12.24, 03:07

типобезопасности обработки ошибок нет

Хотя нет, я тут погорячился - типобезопасность таки есть, безопасности нет

Цитата D_KEY @ 14.12.24, 09:04

Но да, ниже у них написано, что * без проверки сделали для производительности

Ну вот про это я сразу подумал, хотя не читал. Это как-то само собой ...

[D_KEY]

Цитата Majestio @ 14.12.24, 09:32

Цитата D_KEY @ 14.12.24, 09:04

Но да, ниже у них написано, что * без проверки сделали для производительности

Ну вот про это я сразу подумал, хотя не читал. Это как-то само собой ...

Да, конечно. Только в данном случае это удар по самой мотивации введения std:: expected (в отличие от примера с вектором). Цитату я привел.
Достаточно было ввести отдельный метод с говорящим названием.
Ну ещё одна вещь, которую будут зубрить в плюсах и спрашивать на собесах

[Majestio]

Цитата D_KEY @ 14.12.24, 09:54

Достаточно было ввести отдельный метод с говорящим названием.

Остаётся только гадать. Мое предположение такое, что работа именно с указателями в С/C++ является местом более частых багов. Поэтому они решили "о вот вам еще!"

Сообщения были разделены в тему "Ошибки IO не ловятся исключениями"