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

ибо RAII нет

Какой еще RAII в голом Си?

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

дык и в крестах ЕМНИП неавтоматические объекты нужно руками чистить.

цпп не является моим основным языком (говорил выше), знания по нему скорее теоретические (изучал книги: Страуструпа, компиляторы bcc++, Банда Четырех) Писал очень давно расширения для других языков, игрался с tvision.

Насчет деструкторов вроде все понятно: главное не напороться на грабли обращения к несуществующим объектам (были освобождены другими деструкторами или члены класса, зависимые от других классов, вошедших в фазу деструкции) - такое происходило на практике. Только segfault и чтение лога помогло понять в чем дело.

Уже давно почитываю этот тред, хотел добавить, что стоило бы поизучать существующие известные проекты на предмет устаканившейся практики использования исключений. Например у файрфокса (насчет использования там си++ не знаю) или вебкита

Утечки чего?

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

А так стандарт гарантирует вызов всех деструкторов локальных объектов, созданных до вызова исключения.

Гарантирует ли? Было бы полезно взглянуть как этот станарт соблюдается (реализуется) на практике. Хотя бы посмотрев генерируемый код на асме из c++

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

Достаточно для Си

«Кому и кобыла - невеста» (ц). Конечно, любители костыльного секса могут навелосипедить слой поверх setjmp/longjmp, но что с них взять (да и «аналогом» будет именно этот слой, а не сами setjmp/longjmp).

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

Мне нужны исключения хотя бы на уровне SEH, а не убогие setjmp/longjmp. Но спасибо, что разрешил.

Что такое? Дурочка не выключается?

Ты лучше о своей дурочке заботься.

Гарантирует ли?

Да.

как этот станарт соблюдается (реализуется) на практике. Хотя бы посмотрев генерируемый код на асме из c++

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

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

Есть масса любителей. Они даже выдумывают объекты на костылях - GObject, а тут исключения. Плевое дело - макросы нахлобучил и вперед.

Мне нужны исключения хотя бы на уровне SEH, а не убогие setjmp/longjmp

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

Но спасибо, что разрешил.

Не за что. Заходи еще.

Ты лучше о своей дурочке заботься.

Ладно уж, побузили и хватит. Не обижайся.

Гарантирует ли?

Да.

Это вдохновляет конечно.

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

оно понятно, что будет жуткое месиво из ассемблерных команд, но какие-то ___call/jmp будут присутствовать как вызовы деструкторов. Хотелось бы помедитировать над этим минимальным кодом (именно минимальным, чтобы было меньше шумов). Меня всегда интересовало, как выглядит данный кусок кода на асме, хотя бы в общих чертах.

Так вот именно, что никакого. Без RAII(или хотя бы говноfinally) исключения приведут к утечкам или быдлокоду.

В крестах для «неавтоматических» объектов есть как раз идиома RAII, которая говорит нам о том, что у любого ресурса должен быть владелец. Для объекта в динамической памяти такими владельцами являются, например, std::unique_ptr, std::shared_ptr и std::weak_ptr.

Гарантируется и соблюдается как минимум с 1998 года(появление стандарта), а вообще-то с самого появления исключений. Об этом Страуструп даже специально упоминает в D&E, объясняя, почему в С++ не нужен finally.

макросы нахлобучил и вперед.

можно запилить, ну хоть бы и через макропроцессор какой-нибудь.

Система исключений, которую можно запилить через стандартный препроцессор Си - говно. Я видел несколько таких и даже сам пробовал написать - уж лучше возвращать коды ошибок; даже в P99 - говно.

Так это пример того, как исключения готовить не надо. Исключения нужны тогда, когда у тебя происходит исключительная ситуация. И только. Python-стайл в С++ не приветствуется.

но какие-то ___call/jmp будут присутствовать как вызовы деструкторов

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

Я вообще не понимаю, зачем делать из С свой С++, если С++ уже есть. А RAII(одно из основных преимуществ С++ перед С) все равно не сделать...

Неужели нельзя как-то пооптимальнее сделать. ИМХО, под оффтопиком они шустрее(может из-за того, что поверх оффтопиковского SEH реализованы?).

но какие-то ___call/jmp будут присутствовать как вызовы деструкторов

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

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

Без RAII(или хотя бы говноfinally) исключения приведут к утечкам или быдлокоду

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

Я вообще не понимаю, зачем делать из С свой С++

Если речь об исключениях в Си, то их хотели многие (DosSetExceptionHandler в OS/2, что-то аналогичное в Win32, куча костыльных реализаций try-except) и как минимум однажды их сделали (ядро NT и SEH).

А RAII

finally меня вполне устроил бы (я даже считаю, что он должен быть и в Си++ - более того, ON_SCOPE_EXIT и есть finally).

Исключения нужны тогда, когда у тебя происходит исключительная ситуация

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

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

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

А запутаннее разве не хуже? =)

ИМХО, под оффтопиком они шустрее(может из-за того, что поверх оффтопиковского SEH реализованы?).

Не знаю на счет шустрее, но как интересно SEH поможет при раскрутке стека в вашей программе?

Ну не знаю, может вам счеты дать? Там все просто.

через стандартный препроцессор Си - говно

Согласен. Но есть масса других вариантов, вон в Qt пользуются moc и ничего, почти все довольны.

try делать в цикле? Мне кажется тут явно что-то не так с логикой работы.

Мне кажется тут явно что-то не так с логикой работы

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

И что, кроме религии, мешало взять С++?

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

И что, кроме религии, мешало взять С++?

Я не могу ответить на твой вопрос, потому что религия не мешала.

И что им мешало взять С++?

который запускает цикл с парсером.

Ты шлангом-то не прикидывайся. Если нужно отпарсить 10000 файлов, то мне желательно:

1. Узнать какие файлы не прошли парсинг

2.Не падать если 1 из 10000 не прошел.

В любом случае нужно ловить возможное исключение в каждом из 10000 проходов, а значит не важно цикл там у тебя или нет - возможен вариант, что все 10000 будут плохими = дикие тормоза.

Исключения не виноваты в том, что кто-то не умеет их готовить.

И что им мешало взять С++?

Кому «им»? Нам мешало то, что над головой долго висел переход на платформу, где Си++ не поддерживался.

возможен вариант, что все 10000 будут плохими = дикие тормоза.

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

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

Ок. Тормоза исключений будут не так заметны на фоне общих тормозов программы. Весьма слабое оправдание.

Тормоза исключений будут не так заметны на фоне общих тормозов программы.

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

Что это за платформа?

ОС2000

И что, на ней gcc/clang не собираются? POSIX же вроде, не?

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

Оценил каламбур.

(10000 плохих файлов), будет тормозить.

А вы что пишете по принципу: все и так плохо, добавим еще исключения - хуже уже не будет?

А вы что пишете по принципу: все и так плохо, добавим еще исключения - хуже уже не будет?

Мы пишем по принципу «когда всё разваливается, микросекунда уже ничего не решает».

Я кстати, не понимаю, почему было не сделать исключения в виде дополнительного параметра функций, деструкторы вызывать через трюк с goto под капотом и пр. ИМХО, было бы гораздо быстрее того, что сейчас...

http://www.yosefk.com/blog/error-codes-vs-exceptions-critical-code-vs-typical...