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

Видимо у автора этой идеи про «многословность» экономия на спичках головного мозга.

int f2() try
{
	auto_ptr <RetRef> r1 = do_that();
	auto_ptr <RetRef> r2 = do_this();
	do_formatC();
	return 0;
} catch (int ret) {
	return ret;
}

Добавьте сюда код из RetRef, пожалуйста. Пока что я не вижу, чтобы у вас делалось undo_that или undo_this. Впрочем, для php-шников это типично.

А вот читаемый код, который работает, в отличие от нафантазированного RetRef, обладающего навыками телепата и умеющего вызвать undo_that или undo_this в зависимости от положения звёзд.

int f1()
{
    std::vector<Op> todo;
    todo.pushBack(Op(do_that, undo_that));
    todo.pushBack(Op(do_this, undo_this));
    todo.pushBack(Op(do_formatC));
    return performOperations(todo);
}

А вот код, аналогичный вашему убогому второму примеру

int f1()
{
    int code = 0;
    if (do_that(code) && do_this(code) && do_formatC(code))
        return 0;
    return code;
}

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

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

И ребят из pcsx2 тут нет.

А вот код, аналогичный вашему убогому второму примеру

Ты забыл подчистить за собой. Если do_that выделила ресурсы, а do_this провалилась, твой код, который «не убогий», даст течь.

Я ничего не забывал, я написал аналогичный код. Где здесь что-то чистится?

int f2() try
{
	auto_ptr <RetRef> r1 = do_that();
	auto_ptr <RetRef> r2 = do_this();
	do_formatC();
	return 0;
} catch (int ret) {
	return ret;
}

Я ничего не забывал, я написал аналогичный код.

Да, я перепутал.

А вообще, нашли о чём спорить.

Исключения в с++ это костыль. Они засирают стек. Гугл (компания) говорит, что не нужно.

Поэтому в catch нельзя ставить ..., а надо ставить только ожидаемые исключения. В крайнем случае ставить что-то типа MyProjectNamespace::BaseException

ЩИТО?

Главное думать о «гарантиях безопасности исключений»(базовой, строгой, отсутствия исключений). Гугли. Неплохо описано у Саттера в соответствующих главах его «Сложных задач на С++» и «Новых сложных задач на С++».

С чего это он потенциально текущий? Плюсовики усиленно фапают на RAII и гарантии безопасности исключений(описано в их букворях, доках по всяким бустам и пр.). При таком раскладе даже речи об утечках нет. Это вам не сишечка.

Или мы о быдлокодерах?

Больше глобальных переменных
глобальных

Да ты же невменяем. Так и поставлю тебе заметку на будущее: «долбоняша».

Только если new(nothrow) или некорректно перегруженный operator new.

nullable/optional тип пишется легко и непринужденно. Смотри тот же boost::optional.

Где здесь что-то чистится?

Не исключено, в деструкторе RetRef.

Стандарт кодирования для С++ в гугле писали идиоты-неосиляторы(ну или умные дядьки для обезьянок. Но вообще-то даже в хроме ему не следуют. И по слухам внутренний софт тоже пишется не по нему :)

Вы хотели этим сказать, что автор ZeroMQ не знает С++? Всю статью, вместе с примерами кода на С++, за который выгоняют с работы, можно заменить на одну фразу - «я настолько плохо знаю С++, что выбрал С». Ну и исключения он тоже как-то странно воспринимает.

Не исключено, в деструкторе RetRef.

Не исключено, что для выбора между undo_this(), undo_that() и чем-то ещё деструктору RetRef надо обладать навыками телепата или горой хаков.

Не исключено, что для выбора между undo_this(), undo_that() и чем-то ещё деструктору RetRef надо обладать навыками телепата или горой хаков.

Не исключено, что при отсутствии проектирования программа представляет из себя гору хаков, использующих libastral.

С чего это он потенциально текущий? Плюсовики усиленно фапают на RAII и гарантии безопасности исключений(описано в их букворях, доках по всяким бустам и пр.). При таком раскладе даже речи об утечках нет. Это вам не сишечка.

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

Ну как не поставить php программиста, изучающего C++ на дневном в ВУЗе, писать какой-то плюсовый софт на C++ с помощью libmysqlcppconn? А она бросает исключения, т.к. авторы libmysqlcppconn решили воспроизвести интерфейс аналогичной библиотеки для явы.

Вангую наличие внезапных исключений в clucene, т.к. тоже по подобию аналога на яве сделана.

Не исключено, что при отсутствии проектирования программа представляет из себя гору хаков, использующих libastral.

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

Вы хотели этим сказать

Что заголовок переводится как «Почему стоило писать ZeroMQ на C, а не на C++». Кстати, это просто статья, не нравится — не читай.

Так вот пользователь этой библиотеки может не уважать умные указатели в силу малого опыта грабледолбания и большого опыта на php.

Это проблема разработчиков библиотеки? Или может быть причина не использовать исключения?

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

Поскольку тот код фактически ничего не конкретизирует, то далая допущение об адекватности автора, можно предположить по их использованию, что функции do_this и do_that являются фабричными для ресурсов типа RetRef, соответственно их результатом является RetRef, который знает как освобдить свои ресурсы (мы ведь последовательно применяем RAII, не так ли?). А дальше всё сделает auto_ptr.

Это проблема разработчиков библиотеки? Или может быть причина не использовать исключения?

Второе

Поскольку тот код фактически ничего не конкретизирует, то далая допущение об адекватности автора, можно предположить по их использованию, что функции do_this и do_that являются фабричными для ресурсов типа RetRef, соответственно их результатом является RetRef, который знает как освобдить свои ресурсы (мы ведь последовательно применяем RAII, не так ли?). А дальше всё сделает auto_ptr.

Т.е. часть логики из первого примера в примере втором чудесным образом перемещена в do_this() и do_that(). А ещё я не вижу у этих auto_ptr вызова release() при нормальном завершении do_formatC(), так что телепатия ему всё-таки понадобится.

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

А вот читаемый код, который работает,

Этот «читаемый» код говорит только ободном - автор не осилил С++.

Этот «читаемый» код говорит только ободном - автор не осилил С++.

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

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

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

Второе

А то что кто-то мог не осилить шаблоны, это причина не использовать их? А то что кто-то мог не осилить обеспечение потокобезопасности, это причина не использовать потоки?

это причина не использовать потоки

Ага. Асинхронегам с c10k головного мозга epollа хватит всем и для всего :)

Абсолютно верно.

Перед этим хотелось бы почитать какие-нибудь умные буквы о том, почему исключения - это хорошо.

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

В этом смысле, на мой взгляд, лучше всего работает ASSERT. Или я не прав?

Да, хороший ASSERT, с записью в лог строки, модуля, развернутого стека. Ассерты рулят.

использовать в движках игр.

Использование исключений в играх, как минимум плохой тон. А вообще за это в геймдеве руки отрывают. Особенно, если речь идет о консолях.

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

ЕМНИП, «err = fun()», и ворнинга не будет. Но анализа err это не гарантирует.

«unused variable err»

for (std::vector<int>::const_iterator it = var_name.begin(); it != var_name.end(); ++ it) {

А typedef уже не моден? :)

Использование исключений для управления выполнением программы - костыль и зло.

когда дело доходит до критичных к скорости участков, в ход идут костыли.

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

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

Какие есть альтернативы с нормальным контролем освобождения ресурсов и удобочитаемым кодом?

Автопоинтер и ретурн с кодом возврата?

Ну да, вот же где скорость, которой не добиться от исключений. А читаемость какая: ифы, ифы и ретурны... :)

Правильным решением будет забить на рукописный рекурсивный парсер и воспользоваться генератором парсеров.

ведь исключения и производительность несовместимые понятия.

Саму статью читал? Даже если обработка исключений в 100 раз медленнее обработки кода возврата, при обработке кодов возврата 200 раз, исключение бросить и поймать выходит быстрее.

Если у вас модуль вызвает еще один модуль, а тот еще один, а тот еще один, а тот еще один, а тот (и тут еще до 200 раз), то в консерватории что то не так.
И использование исключений подтверждает, что они используются как костыль в кривопродуманной архитектуре.

Саму статью читал?

Читал статьи, где английски по белому сказано - исключения в геймдейве зло. И поясняется почему.
Рекомендую почитать доки от разработчиков для консолей. К примеру для playstation.

Еще на заре рождения 3d studio max (да, первые версии назывлись так), он любил бросать исключения только для того, что бы я понял, что приложение крешнулось и моей работе пришел кирдык. Офигенная помощь от исключений для пользователя - его предупредили, что работа была сделана зря.
Особенно «приятно» было увидеть такое исключение во время сохранения проекта. Даже костыль в диалоге сохранения был придуман - кнопочка «+» которая автоматом именовала файл с инкрементом, дабы не порушить предыдущую версию проекта.

Да, тут виноваты исключения. В продакшене лучше записать некорректный файл молча, что бы пользователь получил приятный сюрприз при следующем открытии. Ну а что, наверное файловая система дурканула. :)

Да, тут виноваты исключения.

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

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

Почему нужно записывать молча некорректный файл? Разве что специально насрать на пользователя.

Поясните, как исключения могут упростить жизнь пользователя?

Поясните, как исключения могут упростить жизнь пользователя?

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

Если у вас модуль вызвает еще один модуль, а тот еще один, а тот еще один, а тот еще один, а тот (и тут еще до 200 раз), то в консерватории что то не так.

Не читал, стало быть. Там меньше одной страницы текста.