Расскажите о философии их использования

Нет просто это очень по детски, вместо технической информации приводить свою автобиографию. :)

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

Вы бы что нибудь технического рассказали. С вашим то опытом. :)

и рассказал о себе

Дочь всё ещё не замужем? :)

Хм, вспомнил одно место, где исключения были необходимы.

Когда-то я велосипедил подобие шарповского метода-делегата (по сути шаблонный functional object с weak_ptr на родительский объект внутри). Если попробовать этот делегат вызвать, когда его родительский объект уже сдох, бросание исключения было единственным способом сообщить об этой утрате.

Дочь всё ещё не замужем? :)

Пока нет. При чем тут моя дочь?

Вы бы что нибудь технического рассказали. С вашим то опытом. :)

Нет, спасибо, больше на подобные провокации я не ведусь.

Нет, спасибо, больше на подобные провокации я не ведусь.

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

При чем тут

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

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

И много вы тут технической информации выдали?

это к беспокойству о раскрытии данных о себе.

Вся эта информация и так есть в свободном доступе. Кому будет нужно, найдет ее и без меня.

Даже странно, что люди путают исключения и ассерты.

Исключительная ситуация != исключение.

/me молча пожимает плечами

И много вы тут технической информации выдали?

Больше вас. Я назвал название игр и движков, исходники которых открыты и в которых можно увидеть использование исключений. Так называемый пруф. :)

Больше вас.

Главное в это верить.

Я назвал название игр и движков, исходники которых открыты и в которых можно увидеть использование исключений. Так называемый пруф. :)

И на основании нескольких движков вы сделали вывод, что исключения используются везде? :)

И на основании нескольких движков вы сделали вывод, что исключения используются везде?

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

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

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

Заявлял. Основания такого заявления я приводил выше.

Заявлял. Основания такого заявления я приводил выше.

Какое из двух выбрать: «ребята из playstation рекомендуют» или «я программирую с 13 лет»? Или оба? :)

Ещё по теме: можно придумать следующий довод против исключений.

Современная действительность радует своим движением в сторону отказа от С++ как языка общего назначения. Вместо этого строится такая картина: тонкие места и тяжёлые алгоритмы на С++ + бизнес-логика на каком-нибудь выразительном высокоуровневом языке.

Создать биндинг вокруг функции или статического метода с++ - не проблема, а вот способа ловить исключения из кода на другом языке, AFAIK, не существует.

Создать биндинг вокруг функции или статического метода с++ - не проблема, а вот способа ловить исключения из кода на другом языке, AFAIK, не существует.

Если ты создаешь биндинг, лови исключения в нем. И вроде SWIG умеет исключения, не?

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

http://www.boost.org/doc/libs/1_53_0/libs/python/doc/v2/exception_translator....

Это не подойдёт?

лови исключения в нем

Ой ли? В ствол С++, отвечающий за исключения, можно засунуть абсолютно любой предмет. Это значит, что (автоматический) генератор биндингов должен на пути от библиотечного вызова к ноге пользователя поставить все возможные барьеры. Либо catch(..), и привет "память не может быть read" либо undefined behavior.

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

лови исключения в нем

Ой ли?

Щито?

Либо catch(..),

Например, недокументированный код возврата - чем он лучше недокументированного исключения?

и привет «память не может быть read» либо undefined behavior.

Это ты так убеждаешь себя, что catch(...) нужен без всяких «либо»?

Например, недокументированный код возврата - чем он лучше недокументированного исключения?

С точки зрения информативности — почти ничем. Он хуже с точки зрения количества лишних сущностей.

s/хуже/лучше/ естественно. Т.е. исключение мы обязаны превратить в код возврата, и оно поэтому лишняя сущность.

Первый раз было правильнее.

Попрошу раскрыть мысль.

Из двух странных высказываний («код возврата хуже с точки лишних сущностей» и «исключение мы обязаны перевести в код возврата, и потому оно лишнее»), первое выглядит более обоснованным (код возврата, обычно целое число, по определению несет в себе много лишних сущностей). Второе высказывание просто неверно: никто тебя не заставляет преобразовывать исключение в код возврата - преобразуй его в исключение, они обычно есть в современном ЯП.

преобразуй его в исключение, они обычно есть в современном ЯП.
преобразуй
обычно

this. Целые-то числа даже в калькуляторе есть гарантированно.

А преобразуй исключение одного языка в исключения другого — это сказать легко, а для реализации понадобятся аж две функции-обёртки: одна, на плюсах, преобразует исключение в структуру языка X (ибо не факт, что из c++ кода можно напрямую бросить исключение языка X), другая, на языке X, кидает его дальше. Многовато сущностей.

для реализации понадобятся аж две функции-обёртки: одна, на плюсах, преобразует исключение в структуру языка X (ибо не факт, что из c++ кода можно напрямую бросить исключение языка X), другая, на языке X, кидает его дальше.

Не понимаю, о чем ты. Биндинг будет на Си++, с перехватом Си++-исключения и созданием исключения $OTHER_LANG через обращение к Си-интерфейсу этого $OTHER_LANG. По крайней мере, так было бы в Guile и Python, и, ЕМНИП, в Java.

обращение к Си-интерфейсу этого $OTHER_LANG

А он точно есть? Короче говоря, функции с кодом возврата можно дёргать напрямую через FFI, а для исключений в любом случае нужна нетривиальная кодогенерация.

обращение к Си-интерфейсу этого $OTHER_LANG

А он точно есть?

Да. Ну или я пока не встречал языков без Си FFI; если ты встречал - расскажи.

Короче говоря, функции с кодом возврата можно дёргать напрямую через FFI,

Ну кто бы спорил, что через убогие FFI современных языков вызвать Си-функцию проще %)

а для исключений в любом случае нужна нетривиальная кодогенерация.

Нетривиальная? Отнюдь не в любом.

Я последние 12 лет пишу на чистом Си.

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

В Си есть setjmp/longjmp - полный аналог исключений.

Нетривиальная? Отнюдь не в любом.

Мы же договорились, что C++ у нас используется только как затычка для тяжёлых алгоритмов. Значит интерфейсы следует проектировать с упором на убогие FFI современных языков. Вся эта возня с исключениями тут ни к чему.

В Си есть setjmp/longjmp - полный аналог исключений.

Полный аналог исключений Си++? Ты в чьем-то чужом уме, и этот ум болен.

Мы же договорились, что C++ у нас используется только как затычка для тяжёлых алгоритмов. Значит интерфейсы следует проектировать с упором на убогие FFI современных языков.

Это да, но это не делает мапинг исключений нетривиальным.

Вся эта возня с исключениями тут ни к чему.

Если «затычка» сама по себе не является чем-то навороченным (так бывает).

Полный аналог исключений Си++?

В контексте Си - да, полный. Ты вообще в курсе, что try/catch запилили только потому, что longjmp не вызывает деструкторы?

Ты вообще в курсе, что try/catch запилили только потому, что longjmp не вызывает деструкторы?

Интересно откуда такая информация. Это сам Страуструп вам сказал?

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

И получишь дичайшие тормоза:

Пример 1

#include <iostream>

struct Test {
    int a,b,c;
    int *buf;
    Test(): a(0), b(0), c(0), buf(new int[100]) {}
    ~Test() { delete[] buf; }
};

int foo(int parm) {
    Test me;
    if (parm==200) return parm;
    return foo(++parm);
}
    
int main() {
    int res=0;
    for(int i=0;i!=100000;++i) res+=foo(0);
    std::cout << res << "\n";
    return res;
}

Пример 2

#include <iostream>

struct Test {
    int a,b,c;
    int *buf;
    Test(): a(0), b(0), c(0), buf(new int[100]) {}
    ~Test() { delete[] buf; }
};

int foo(int parm) {
    Test me;
    if (parm==200) throw parm;
    return foo(++parm);
}
  
int main() {
    int res=0;
    for(int i=0;i!=100000;++i) try { foo(0); } catch(int p) { res+=p; }
    std::cout << res << "\n";
    return res;
}

Проверяем:

$ time -p ./p1
20000000
real 1.70
user 1.70
sys 0.00

$ time -p ./p2
20000000
real 47.61
user 47.49
sys 0.02

В контексте Си - да, полный.

Чушь. Для начала - где языковая конструкция обработки исключений, с несколькими ветками для исключений разных типов и finally (если уж у нас нет раскрутки стека)? А как вернуть из setjmp, например, структуру?

Ты вообще в курсе, что try/catch запилили только потому, что longjmp не вызывает деструкторы?

Нет, я не интересуюсь этим разделом мифологии.

Для начала - где языковая конструкция обработки исключений, с несколькими ветками для исключений разных типов и finally (если уж у нас нет раскрутки стека)?

Для начала изучи хотя бы википедию http://en.wikipedia.org/wiki/Setjmp

А как вернуть из setjmp, например, структуру?

Ну, например, используя параметр int как указатель. А еще лучше как указатель на структуру - описатель исключения в которую заворачивается указатель на структуру описатель конкретного исключения и его тип т.п. извращения в стиле голого Си.

Но ты же 12 лет на Си пишешь, зачем я тебе это объясняю?

Для начала - где языковая конструкция обработки исключений, с несколькими ветками для исключений разных типов и finally (если уж у нас нет раскрутки стека)?

Для начала изучи хотя бы википедию http://en.wikipedia.org/wiki/Setjmp

Это не Википедия утверждала, что «setjmp/longjmp - полный аналог исключений Си++». Впрочем, по ссылке нет ничего из того, о чем я спрашивал.

А как вернуть из setjmp, например, структуру?

Ну, например, используя параметр int как указатель

Я специально спрашивал о структуре, а не указателе.

зачем я тебе это объясняю?

Не знаю. Тем более, что я задал конкретные вопросы, на которые ты не ответил.

Господа разработчики, было бы интересно и полезно взглянуть на минимальный код c++ с исключени(-ем/-ями) на асме, порождаемый компилятором. Кому не в лом, запостите пожалуйста такой листинг. Благодарю.

Меня заинтриговала, та мысль, что исключения не всегда хорошо именно в c++ и (возможно ошибаюсь) могут служить источником утчеки на уровне порождаемого кода. Хотелось бы разобраться. Думаю будет полезно многим.

Впрочем, по ссылке нет ничего из того, о чем я спрашивал.

Ок. Тогда прокомментируй конкретно вот этот абзац http://en.wikipedia.org/wiki/Setjmp#Exception_handling

Я специально спрашивал о структуре, а не указателе.

Тебе надо объяснять, как получить структуру по указателю на нее?

Не знаю. Тем более, что я задал конкретные вопросы, на которые ты не ответил.

О-хо-хо. Давай-ка, выключай дурочку - «не знаю, не понимаю».

вот этот абзац http://en.wikipedia.org/wiki/Setjmp#Exception_handling

setjmp/longjmp можно использовать как обоработки исключений. По твоему, этого достаточно, чтобы назвать их «полный аналог исключений Си++»? Я даже больше скажу - ранние системы обработки исключений для Си++ использовали setjmp/longjmp под капотом. Нынешние системы, кстати, построены на DWARF - теперь у нас и DWARF является полным аналогом исключений?

Тебе надо объяснять, как получить структуру по указателю на нее?

«Давай-ка, выключай дурочку»

я задал конкретные вопросы, на которые ты не ответил.

О-хо-хо.

Что такое, забыл вопросы? Напомнить?

Утечки чего? Если деструкторы писать не умеешь или RAII не понимаешь, то да, будут утечки. А так стандарт гарантирует вызов всех деструкторов локальных объектов, созданных до вызова исключения.

Можно подробнее о DWARF?

По твоему, этого достаточно, чтобы назвать их «полный аналог исключений Си++»?

Достаточно для Си. Или ты забыл, что жаловался как в Си тебе не хватает try/catch? Ну так вот - пользуйся longjmp.

Что такое, забыл вопросы? Напомнить?

Что такое? Дурочка не выключается? До сих пор никак не можешь передать структуру через longjmp? Или сделать switch/case по типу переданного исключения? Хватит уже позориться-то, разработчик на Си.

С longjmp у тебя будут утечки или куча текста для освобождения ресурсов руками, ибо RAII нет, а gcc'шный cleanup атрибут не работает при longjmp.

Да и зачем в Си исключения? Не проще ли взять С++?

Можно подробнее о DWARF?

Я сам уже точно не помню :) В DWARF хранятся регионы адресов участков кода и описания стековых кадров, и это как-то позволяет избежать setjmp в try-блоке. Гугл имеет сказать следующее: http://stackoverflow.com/questions/87220/how-does-gcc-implement-stack-unrolli... http://llvm.org/docs/ExceptionHandling.html (Itanium ABI Zero-cost Exception Handling).