C vs C++ , Не опять а снова

[D_KEY]

[Wound]

Цитата D_KEY @ 08.09.19, 18:17

Так это и будет тот самый мусорный код.

Какой еще мусорный код? О чем ты?

Добавлено 08.09.19, 18:21
У тебя выходит такой же мусорный код будет везде где ты пишешь throw

[D_KEY]

Цитата Wound @ 08.09.19, 18:20

Цитата D_KEY @ 08.09.19, 18:17

Так это и будет тот самый мусорный код.

Какой еще мусорный код? О чем ты?

Про проверку кода и return. Для того, чтобы покинуть ошибку выше, придется это писать для каждого вызова. Для исключений тебе ничего не нужно делать.

[Wound]

Цитата D_KEY @ 08.09.19, 18:23

Про проверку кода и return. Для того, чтобы покинуть ошибку выше, придется это писать для каждого вызова. Для исключений тебе ничего не нужно делать.

Ну как это не придется придется, иначе потом тебе придется еще внедрять и SEH, ликбез про который выше выложил Qraizer.
Ты как пишешь то?
Вот как то так?

void SomeMethod(SomePtr* ptr)
{
   ptr->SOmeMethod();
}

Добавлено 08.09.19, 18:29
Ну и плюс с кодами возврата - мне ведь нужно проверить код возврата.
Т.е. я пишу

if( someFunction(/*...*/) == err)
          return err;
...

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

[D_KEY]

auto rc = f1(x, y, &r1);
if (rc) {
    return rc;
}
 
rc = f2(a, b, &r2);
if (rc) {
    return rc;
}
 
rc = f3(r1, r2, &r3);
if (rc) {
    return rc;
}

vs

auto r1 = f1(x, y);
auto r2 = f2(a, b);
auto r3 = f3(r1, r2);

Или даже

auto r = f3(f1(x, y), f2(a, b));

Добавлено 08.09.19, 18:33

Цитата Wound @ 08.09.19, 18:26

Ну как это не придется придется, иначе потом тебе придется еще внедрять и SEH

Зачем?

[Wound]

Цитата D_KEY @ 08.09.19, 18:31

Или даже

Ровно тоже самое можно сделать с кодами ошибок. Вам же там в С++ уже и кортежи завезли и тьюплы разные, возвращать всякие структуры по идее должно быть просто.
Как ты организуешь так и будет.

[D_KEY]

Цитата Wound @ 08.09.19, 18:26

Ты как пишешь то?
Вот как то так?

void SomeMethod(SomePtr* ptr)
{
   ptr->SOmeMethod();
}

Что это? Не понял, какая связь с обсуждением. Но у меня тут будет или not_null<SomePtr*> или проверка на nullptr.

[Wound]

Цитата D_KEY @ 08.09.19, 18:31

Зачем?

Ну как зачем то. Потому что при отключенной настройке перехватывать системные исключения, очень много исключений(системных) твой catch не споймает.
Например, как ты напишешь функцию, которая на вход принимает 2 числа, и возвращает результат от деления?

[D_KEY]

Цитата Wound @ 08.09.19, 18:35

Цитата D_KEY @ 08.09.19, 18:31

Или даже

Ровно тоже самое можно сделать с кодами ошибок.

Покажи. С кодами возврата будет так, как я в начале написал.

Добавлено 08.09.19, 18:39

Цитата Wound @ 08.09.19, 18:36

Потому что при отключенной настройке перехватывать системные исключения, очень много исключений(системных) твой catch не споймает.

Ну значит я проверю сам и кину исключение(или еще как-то обработаю)

[Wound]

Цитата D_KEY @ 08.09.19, 18:36

Что это? Не понял, какая связь с обсуждением. Но у меня тут будет или not_null<SomePtr*> или проверка на nullptr.

Вот именно, проверка на nullptr - как раз и есть одно из "проверка кода возврата на ошибку". Т.е. ты не можешь написать так как выше, т.к. при нулевом указателе, ЕМНИП, обычный catch(...) ничего не споймает.
В тех же явошарпах такие ошибки можно ловить, с помощью catch, а в С++ не прокатит такой трюк. AV не ловиться обычным механизмом исключений(если не выставить специальную настройку).
И в итоге как ни крути ты хочешь не хочешь, а от кодов ошибки ты никуда не уходишь, хоть исключения и создают тебе такую иллюзию.

Добавлено 08.09.19, 18:40

Цитата D_KEY @ 08.09.19, 18:37

Покажи. С кодами возврата будет так, как я в начале написал.

Возвращать например структуру, которая содержит результат и код ошибки.

Добавлено 08.09.19, 18:41

Цитата D_KEY @ 08.09.19, 18:37

Ну значит я проверю сам и кину исключение(или еще как-то обработаю)

Так а чем это отличается от возврата ? Ровно те же яйца, только в профиль. Вот даже выше applegame про это и пишет.

[D_KEY]

Цитата Wound @ 08.09.19, 18:40

Вот именно, проверка на nullptr - как раз и есть одно из "проверка кода возврата на ошибку"

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

[Wound]

Цитата D_KEY @ 08.09.19, 18:43

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

Так это на сколько я понимаю, твой not_null - обычный враппер с проверкой на Null. То есть тот же мусорный код, только завернутый в обертку. По поводу проверки аргументов, не совсем. В данном случае - это был пример с аргументом, можно так же взять функцию, которая возвращает тебе указатель. Вот как раз это и есть код возврата. Если он нулевой - значит ошибка, если не нулевой, значит все впорядке. Например в WinAPI есть еще такая функция как getLastError. По сути вообще можешь забить болт на все коды ошибок, которые тебе возвращают функции. А вот там где надо, просто вызываешь getLastError и смотришь - если 0, значит никаких ошибок не было, а если не 0, значит какая то ошибка затесалась. Она тебе вернет код ошибки, дальше есть спец функция, которая тебе ее преобразует в читаемый текст. Ровно таже обертка.

[D_KEY]

Цитата Wound @ 08.09.19, 18:40

Возвращать например структуру, которая содержит результат и код ошибки.

Ты про Either(result<T, E>) и Maybe(option<T>)? Ну да, это уже вроде обсуждалось.
Я за использование этого там, где "ошибка" - такой же валидный с точки зрения логики приложения результат. Например, при поиске чего-то в коллекции вполне логично возвращать option, чем кидать исключение.

[Wound]

Цитата D_KEY @ 08.09.19, 18:48

Ты про Either(result<T, E>) и Maybe(option<T>)? Ну да, это уже вроде обсуждалось.

Я это не юзал, но судя по вашему обсуждению - да, про это. Вся фишка в том, что можно написать и на исключениях трешак, ровно так же как и на кодах возврата.
Но лично как по мне, понять/запомнить какие ошибки может вернуть функция, взглянув на ее сигнатуру - проще, чем сделать то же самое с исключениями. Но опять же все зависит от того, как ты все это напишешь.
Например если функция возвращает ошибку как Enum, то тут уже просто через точку уже можно сделать вывод какие ошибки она в принципе может вернуть. А с исключениями как? Указывать спецификацию исключений, которые может генерить функция - как вариант, да, тут не спорю. Но ведь это нужно явно писать все руками. И везде замудохаешься это писать. Вот в чем проблема.

[D_KEY]

Цитата Wound @ 08.09.19, 18:47

Так это на сколько я понимаю, твой not_null - обычный враппер с проверкой на Null.

Ты не знаком с C++ Core Guidelines? Рекомендую. Про not_null: Declare a pointer that must not be null as not_null

Есть библиотека для поддержки этого - gsl.

Добавлено 08.09.19, 18:58

Цитата Wound @ 08.09.19, 18:47

То есть тот же мусорный код, только завернутый в обертку.

Мусорным этот код становится от того, что его приходится писать на каждый вызов. Как я показал выше. И к чему относится картинка с особенной клавиатурой. В случае not_null мне не приходится писать такой код. И никакого мусора нет.