LINUX.ORG.RU

exceptions в C++

 ,


5

9

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

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

UPD:
Из любопытного
почитать (стр. 32)
посмотреть

★★★★★

Последнее исправление: morse (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Если кратко, то современные исключения имеют ничтожные накладные расходы

Ну там этого не написано, там есть частный случай где они быстрее. Вот пример разницы в 30 раз в пользу кодов возврата: https://youtu.be/oXw2vXOUr1g?t=3m50s

CrossFire ★★★★★
()
Ответ на: комментарий от CrossFire

Ну надо сказать что в видосике тоже случай специфичный. Там исключения бросаются в 50% вызовов, а код возврата реализован через bool. Статейка честнее - они рассмотрели два параметра: глубина стека и вероятность исключения. Причем вероятность более вменяемая - менее 10%. А ошибка при этом - честный struct со строкой, а не читерский bool.

Но вывод прямо противоположный: в реальной жизни (невысокий стек вызова) коды возврата быстрее уже с вероятности 1-2%. эксепшены быстрее только на чистом коде.

morse ★★★★★
() автор топика
Ответ на: комментарий от CrossFire

Если точнее, то там написано, что всё зависит от ситуации. И ручной проброс значение будет медленнее исключений. Особенно учитывая то, что исключения можно ловить разных типов, в отличии от.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

«Код возврата» тоже может быть полиморфный (или какой-нибудь variant/enum).

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Я про плюсы. Там только Variant, который не безопасный (нужно самому проверять наличие в нём нужного типа, в то время как match в rust делает это за нас на этапе компиляции).

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Я про плюсы. Там только Variant, который не безопасный (нужно самому проверять наличие в нём нужного типа

Можно написать свой.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Свой вариант? Но зачем, если уже есть существующий? Тем более я не вижу как получить гарантии растовского enum в плюсах.

То есть в плюсах я могу написать variant.toString(), а она на самом деле Rect, и получу мусор. В раст так не получится, ибо PM.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Ты вынужден будешь писать sum_val.as<SomeType>().some_method(). Если sum_val не содержит SomeType, ошибка компиляции; если текущее значение adt_val имеет другой тип, бросается std::logic_error.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

Но match проверяет при компиляции

При компиляции match компилятор проверяет наличие SomeType в типе; при компиляции as<SomeType> делается то же самое. Наличие значения типа SomeType в переменной проверяется динамически.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

Можно пример кода? Какая-то шаблонная магия, не иначе.

тебе бы книжки почитать, умнее станешь)

anonymous
()
Ответ на: комментарий от anonymous

Этот фрагмент даже с Modern C++ Design не сравнить, куда там Folly.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.