egorychWhite OwlКак ты собираешься сделать это на исключениях?
если прям совсем в лоб, то как-то так ( тупой способ, я знаю. тут дизайн всего решения неплохо было бы поменять, конечно ) :Ну так поменяй. Ты же не забыл итоговую цель? Показать что ту-же самую задачу с исключениями решать проще, элегантнее, короче, и тп чем с кодами возврата. Пока это не было продемонстрировано.
Я показал кусок реального кода решающего простую задачу. Покажите мне более удобное решение той же задачи в парадигме исключений и я перестану плеваться в их сторону.

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

MasterZivОдно только спрошу: на ноль как делить будем, какой код возврата проверять будем, или может быть аргументы проверять будем ?
Как вообще ?Как вообще? Да элементарно! Проверим делитель перед арифметикой и будем иметь возможность либо просто задать результат в одну из констант (ноль или бесконечность, смотря что нужно по логике расчетов) или выругаемся юзеру на экран, мол дай правильное значение для делителя.
Все очень просто: я, зная что вот тут могут быть проблемы, изначально пытаюсь их минимизировать. А ты, привыкнув к подходу: "проблема? Потом поймаем", борешься со следствием проблемы. Мы в итоге просто по разному мыслим.

MasterZivКое-какие осилянты тоже против, типа WO (я не думаю, что он неосилил EH за столько лет стажа в специальности).Ах! Ну хоть кто-то в меня верит :)


MasterZivЯ ещё раз повторяю, ислючения были в IT ВСЕГДА, с момента ЗАРОЖДЕНИЯ индустрии.
Это те же деления на ноль, потери значимости, обращения по несуществующему или нулевому адресу и т.д.
Раньше это называлось системные прерывания. Иногда ещё как-то по-другому, не важно.
Теперь просто таких случаев стало больше, появилась возможность ими управлять, появилась возможность
их обрабатывать, и они стали определяться не на низшем уровне абстракции, а на более высоких.
Суть от этого не меняется -- мы определяем операции, которые в каких-то случаях невозможно выполнить,
и продолжать процесс вычисления после них невозможно.Ты путаешь исключения и исключения .
То что ты описал, что было всегда, это аварийные ситуации и они действительно были всегда и будут всегда и их до сих пор сложно ловить на прикладном уровне. Но исключения на которые я плююсь это исключения порождаемые программистом, уже на прикладном уровне.
Это действительно два разных типа исключений и они даже синтаксически в С++ обрабатываются по разному, да еще и ОС-зависимо.
Да, исключения которые ловятся через __try{}__catch(){} или sigaction() это действительно "исключения которые были всегда". И это действительно настоящие исключения.
Но дизайн приложения основанный на throw()+try{}catch(){}... это плохая идея ведущая к нечитаемому и соответственно трудно поддерживаемому коду.


MasterZivТак что в принципе даже обсуждать тут нечего. Исключения были, есть и будут, и вредны они для отрасли или полезны, были ли они ошибкой или не были, -- спорить бессмысленно. Они были, есть и будут, и с ними нужно уметь жить и работать.Аварийные ситуации были есть и будут... Но так ли уж надо их еще и вручную создавать?

SiemarglВообще то есть два пути написания надежных программ:

-берем обычный язык (С, неважно) и накладываем на него кучу правил-ограничений и науськиваем программу-проверялку их выполнения
-берем язык, в котором изначально эти ограничения встроены (Java, Rust, D) и боремся с ними в попытке сделать что то полезное =)Ну да, где-то так. Но ...
Если человек сам сознательно наложил на себя кучу ограничений - это одно. А если эти наложения наложили на него другие - это уже ущемление прав и человек будет стремиться сорвать оковы. Чистая психология :)

SiemarglПохоже, на мой вопрос 20657004 ответа никто не знает....Почему-же, знаем. Просто он слишком простой.
STL была изобретена убежденным апологетом обобщенного программирования и в первой реализации она действительно следовала заявленным O(x) для всех имеющихся там шаблонов. Прошли годы, и спустя многие реализации (и переписывания с нуля) она в основном продолжает следовать заявленным характеристикам. А в частности, в той инсталляции библиотеки которая у тебя есть - ты вряд-ли сможешь найти расхождение с заявленной в документации производительностью. Но в паре-тройке функций может быть и проседание (от ошибок никто не застрахован, в том числе и люди пишущие библиотеки).