Поддерживает ли C++ блоки «finally»? (И что это за RAII, о котором я все время слышу?)

«Разрушение - это отказ от ресурсов» - DIRR ... Нет, у меня не работает. = P

RAII застрял - его действительно нельзя изменить. Было бы глупо пытаться это сделать. Однако вы должны признать, что «Получение ресурсов - это инициализация» - все еще довольно плохое название.

Действительно плохое имя, я все еще не могу понять его.

Я согласен с названием - жаль, что мы застряли с ним.

SBRM == Управление ресурсами, связанными с областью действия

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

@Kevin: Во время использования RAII действительно не похож на using: вы не можете объединить оператор using с инициализатором / финализатором вашего класса. Вы должны быть точными и не забывать using-утверждение. Вложение становится ужасным. Варианты использования using по сравнению с RAII в основном равны нулю: блокировки с ограниченным объемом, векторы, строки, общие указатели, транзакции и все остальное без необходимости вручную писать using(). Как вы это представляете, using - плохая защита перед RAII, и я понимаю, что многие разработчики .net изо всех сил пытаются убедить себя, что RAII похож, но в глубине души они (должны) знать, что это не так.

Это заставляет вас застрять, когда вам нужно что-то очистить, что не соответствует времени жизни любого объекта C++. Я предполагаю, что вы получите Lifetime Equals C++ Class Liftime Or Else It Gets Ugly (LECCLEOEIGU?).

Я думаю о чем-то похожем на Уоррена: подождите, что произойдет, если у вас есть код, который должен обязательно выполняться, но не в конце жизненного цикла объекта? Разве еще не существует варианта использования слова «finally», и поэтому его отсутствие в C++ - это дыра в пространстве дизайна? Кроме того, использование деструктора означает, что C++ всегда должен реализовываться с использованием ДЕТЕРМИНИСТИЧЕСКОГО времени жизни памяти. Ни одна из будущих версий C++ не сможет использовать вместо этого сборку мусора, потому что все полагаются на своевременное выполнение деструкторов.

@WarrenP Тогда вы должны обернуть это "что-то" в класс. В этом вся суть RAII, и на самом деле он часто заставляет вас делать лучший дизайн.

@ToolMakerSteve То же самое и с вами, заверните. Это также не дыра в дизайне, поскольку, если вы хотите сделать gc на C++, вы, вероятно, сделаете это с необработанными указателями (или, может быть, с конкретным классом указателя, но тогда это еще менее актуально), а удаление всегда происходит перед gc может вмешаться. Другими словами, это повлияет только на сломанный (/ утечку) текущий код, в котором вы уже не могли полагаться на конструкторы.

@Jasper: Вот почему в каждой кодовой базе так много почти совершенно бесполезных классов. Потому что C++ не оставляет вам другого выбора. Это называется языковой бородавкой.

@WarrenP Нет, это называется принцип единственной ответственности.

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

Что ж, лично я предпочитаю, когда язык решает не творить магию, а вместо этого дает вам мощные инструменты, чтобы делать что-то самостоятельно, и сообщая, что единственный способ сделать это - поддерживаемый и масштабируемый способ, который решает проблему внутри кода. честно говоря, для меня не проблема. Посмотрите на альтернативы, Java передает это в руки вызывающего кода с finally, C# дает тот же метод и некоторую магию через using, языки сценариев часто дают вам аналогичные решения, но также говорят, что ограниченное время выполнения должно предотвратить большие проблемы. Я бы взял RAII в любой день.

@Jasper: Обертывание в класс, очевидно, имеет смысл, когда (управляемое состояние) является частью того, что делает служба. Однако это кажется обременительным, когда это единовременная потребность (клиента или кода графического интерфейса пользователя) как часть ответа на конкретное действие пользователя. Например, в какой-то момент моей клиентской логики мне нужно запомнить текущее значение нескольких (полей механизма рендеринга - я не могу изменить его исходный код), установить для них необходимые значения, а затем восстановить их, когда это будет сделано. Создание класса для этого единственного использования в единственной процедуре - это излишне. «Наконец-то» было бы кратким и безопасным решением.

@Jasper: Я удалил один из своих комментариев - решил, что добавление недетерминированный GC в C++ сделает и без того слишком сложный язык еще более головокружительным. Настоящая проблема заключается в том, что годы, которые я программировал на C++, до появления Java или .Net, я считал это неприятным - и все еще чувствую, когда мне нужно его использовать. Я бы хотел увидеть новое изобретение C++, начиная с нуля, которое было бы таким же чистым, как python или C#, с библиотекой классов, основанной на RAII, интеллектуальных указателях и / или слабых ссылках: решения детерминированный GC. Да, все, что существует в C++, но более чистый язык для размышлений. По общему признанию, не по теме ...

@ToolmakerSteve Перед этим удалил один из моих ответов на него: P, когда я понял, что совершал ошибку. В любом случае, я согласен с тем, что чистый неуправляемый язык был бы замечательным (или, возможно, даже мог бы быть хороший способ смешать управляемый и неуправляемый). Даже Бьярн Соуструп в основном сказал то же самое (теперь он предпочел бы не иметь багажа C-совместимости, но он не может изменить это сейчас). Я обнаружил, что необходимость думать о владении - это хорошо. Конечно, вы почти всегда должны использовать вещи C++ вместо C-вещей, что не всегда случается и не всегда было возможно в те времена, когда Java еще не существовала.

Лично я не считаю, что RAll действительно хорошая альтернатива блоку finally. Это просто означает, что для правильной очистки вы должны заключить ресурсы в искусственные объекты, чтобы получить автоматическую очистку, как указал Уоррен П. в своем комментарии выше (Language wart).

@Devolus Вы можете создать очень простой объект-шаблон, чтобы делать это для любых двух методов, которые вам нужно вызвать при инициализации и деинициализации. Честно говоря, я бы не удивился, если бы такой шаблонный класс уже был в STL. (Но его, скорее всего, нет (пока?))

Да, потому что это намного меньше кода, чем <snark> mutex_.lock (); попробуйте {foobar (); } наконец {mutex_, unlock (); } </snark> объекты-оболочки, шаблоны, мальчик, этот C++ 11, конечно, намного проще!

@TonyBenBrahim Умножается на всю вашу базу кода, применяется ко всем ресурсам, для которых вам нужна детерминированная очистка? да. Да, это так.

@Cubic, да, теперь я это понимаю. Однако требует некоторого привыкания, исходящего от Java.

@Jasper Я могу придумать ситуацию (возможно, необычную, но я не знаю), в которой, вероятно, было бы чище иметь хотя бы try...finally, при условии, что он не нужен в нескольких местах: Работа напрямую с оборудованием. Предположим, что определенная ячейка памяти обычно должна иметь флаг "все очищено", но этот флаг следует изменять во время определенных операций. Если эти операции выполняются одной функцией, было бы чище иметь try { uintX_t* flag = some_address; *flag = WHATEVER; /* ... */ } finally { *flag = ALL_CLEAR; },

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

Однако в целом RAII определенно является более чистой альтернативой, IMO. Мне просто странно, что в языке нет и того, и другого, хотя иногда простой одноразовый может быть чище, чем класс, который используется только в одном конкретном месте для одной конкретной задачи.

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

@Jan Этого нет в стандартной библиотеке C++, но есть BOOST_SCOPE_EXIT, если вы можете простить синтаксический шаблон, и что тело вашего кода не должно бросать. boost.org/doc/libs/1_65_1/libs/scope_exit/doc/html/scope_exi‌ t /…

нам нужно наконец, точка.

Нет, мы этого не делаем. Период.

Немного сложное объяснение после того, как вы написали основную идею разрушения, чтобы освободить память (это было более ясно до того, как я начал читать последнюю часть ответа), но все равно спасибо!

Я согласен с тем, что RAII элегантно решает проблему обеспечения освобождения ресурсов. Это не решает изящным образом, гарантируя, что что-то всегда будет выполняться (например, ведение журнала).

имейте в виду, что на самом деле это не исключения C++, а исключения SEH. Вы можете использовать и то, и другое в коде MS C++. SEH - это обработчик исключений ОС, который реализует исключения в VB и .NET.

и вы можете использовать SetUnhandledExceptionHandler для создания «глобального» обработчика невыявленных исключений - для исключений SEH.

SEH ужасен, а также предотвращает вызов деструкторов C++

Это очень хороший момент. +1 вам. Однако не так много людей проголосовали за вас. Надеюсь, вы не возражаете, что я отредактировал свой пост, включив в него ваши комментарии. (Я, конечно, отдал вам должное.) Спасибо! :)

// Make sure not to throw exception if one is already propagating. Для деструкторов C++ также важно не генерировать исключения именно по этой причине.

@Cemafor: причина, по которой C++ не выбрасывает исключения из деструктора, отличается от Java. В Java это будет работать (вы просто потеряете исходное исключение). В C++ это действительно плохо. Но суть C++ в том, что вам нужно сделать это только один раз (разработчиком класса), когда он пишет деструктор. В Java это нужно делать в момент использования. Таким образом, пользователь класса несет ответственность за то, чтобы в любое время написать одну и ту же шаблонную пластину.

Если дело в том, что вы «нужны», вам тоже не нужен RAII. Избавимся от этого! :-) Шутки в сторону, RAII подходит во многих случаях. RAII делает более громоздким те случаи, когда вы хотите выполнить некоторый код (не связанный с ресурсами), даже если приведенный выше код был возвращен раньше. Для этого вы либо используете gotos, либо разделяете его на два метода.

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

@LokiAstari О, это довольно просто, представьте, например, что я создаю структуру данных из файла XML и хочу распечатать ее в конце функции. Дело в том, что в моем коде есть куча return в загрузочной части, поэтому мне не придется делать много if в будущем. RAII был бы очень громоздким, так как мне потребовалось бы создать класс только для того, чтобы сделать красивую печать, нелепо. Либо вы используете goto вместо return, либо отделяете загрузку от печати как разные функции. Я согласен, возможно, это не лучший пример, но нелепо думать, что RAII = наконец

@Trinidad: Это не так просто, как вы думаете (поскольку все ваши предложения, кажется, выбирают худшие из возможных вариантов). Вот почему вопрос может быть лучшим местом для изучения этого, чем комментарии.

наконец, java 7+: попробуйте (DB db = new DB ("DBDesciptionString")) {// используйте db}

@TonyBenBrahim: По крайней мере, Java движется к C++ небольшими шагами. Но это принятие директивы использования C#. Шаг, но не такой мощный, как RAII ;-)

Хотя я думаю, что ваш ответ очень хорош, я бы возражал против «из-за RAII». Думаю, лучше было бы сказать: «нет, но вы можете избежать промаха, используя RAII».

Итак, если деструкторы C++ не могут генерировать исключения и не имеют возвращаемых значений, как, черт возьми, вы должны сообщать об ошибках? Например, если деструктору соединения с базой данных необходимо зафиксировать или откатить незавершенную транзакцию, или если деструктору файлового потока необходимо очистить буфер, и эта операция завершится неудачно по какой-либо причине. Вы можете решить эту проблему, введя явную функцию очистки (close / dispose / disconnect / etc.), Которая возвращает код ошибки, но в основном это делает бесполезными неявные вызовы деструктора C++.

@ dan04: деструкторы C++ МОЖЕТ генерируют исключения. Обычно это не самая лучшая идея. Они просто не могут сгенерировать исключение, когда исключение уже распространяется. См .: stackoverflow.com/questions/130117/… и codereview.stackexchange.com/questions/540/… (прочтите последний комментарий к этому).

@ dan04 Для этих случаев есть другая идиома. Это называется защитой прицела. Страж области видимости принимает лямбда-указатель / указатель на функцию / все, что вы хотите, при построении и выполняет его при уничтожении. Это позволяет вам определить раздел кода, который эффективно работает как блок finally, за исключением того, что код очистки можно легко отключить, изменить для других областей или внедрить в другие места. Я вообще не рекомендую использовать исключения в любом неявно вызываемом коде (деструкторах IE), так как это может привести к возникновению исключений в непредвиденное время.

Критика «НЕ требуется из-за RAII»: существует множество случаев, когда добавление специального RAII было бы слишком большим количеством шаблонного кода для добавления, а попытка наконец-то была бы просто чрезвычайно уместной.

@ceztko Я бы сказал, что try / finally использует гораздо более bolierplate. Проблема в том, что try / finally нужно выполнять каждый раз, когда он используется (см. Пример выше). Хотя RAII должен быть выполнен первоначальным автором только один раз. Другая проблема с try / finally заключается в том, что вы перекладываете бремя правильного использования с автора на пользователя. Заставить пользователя делать это каждый раз правильно намного сложнее, чем заставить автора делать это правильно один раз.

@MartinYork Я не говорю, что вместо RAII всегда следует использовать try-finally. Вы правы в том, что API-интерфейсы должны предоставлять соответствующие деструкторы для своих структур или обеспечивать защиту RAII, где это необходимо (например, для обработки транзакций). Я говорю о том, что в конечном пользовательском коде есть некоторые обстоятельства, когда добавление RAII - не самый надежный инструмент, который он, возможно, захочет использовать, и попытка наконец-то выполнит свою работу без создания скучных специальных структур для RAII. Короче говоря: было бы хорошо иметь и то, и другое, и мудрый программист использовал бы наиболее подходящие в каждой ситуации.

@MartinYork Иногда различие «пользователь против автора» просто не применяется. Скажем, в конце моего main() я хочу записать файл с надписью ERROR или OK, в зависимости от того, что произошло. Я бы сделал что-нибудь вроде bool ok = false; try { /* do stuff */; ok = true; } catch (...) { ... } finally { write_my_file(ok); }. Теперь мне нужно написать для этого класс, и я становлюсь «автором» класса, который мне не понадобился бы, если бы я мог исправить это как «пользователь».

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

@PieterNuyts bool ok = false; gsl::final_act finalAction([&ok](){write_my_file(ok);}); /* do stuff */; ok = true; Мне кажется, он намного менее напыщенный.

@MartinYork, На первый взгляд, ваш фрагмент кода примерно такой же длинный, как и мой (и вы пропустили блок try / catch, который все еще понадобится), поэтому я не уверен, почему вы считаете его менее сложным. Но любой, кто хочет понять вашу, должен знать или искать, что такое gsl::final_act и как именно он работает.

@PieterNuyts Все дело в том, что вам не нужен блок try / catch (или наконец), поскольку все, что будет сделано, - это соответствующий деструктор. В добавляемом мной примере finally есть простой альтернативный метод обеспечения функциональности finally, если вы действительно этого хотите. Обычно вы этого не делаете, но его просто добавить в C++. Что касается знания того, что делает final_act: переход к ближайшему к вам стандарту (C++ gsl => modernescpp.com/index.php/…)

@PieterNuyts Вот как я это вижу. Более чем счастлив обсудить эту тему, если хотите.

Никакой деструктор не может заменить блок catch, поскольку деструкторы не могут перехватывать исключения, созданные извне. Таким образом, вы можете отбросить блок finally, но вам все равно понадобится try / catch (конечно, при условии, что вы хотите перехватить и обработать исключение).

Вы правы, что я не учел исключения внутри блока finally. Итак, ваш код, возможно, немного короче. Тем не менее, то, что какая-то функция является или становится частью стандарта, не означает, что люди автоматически знают ее точное имя и подпись наизусть. Конечно, вам также нужно знать, что означает finally, но мне кажется, что это намного легче запомнить, по крайней мере, мне. Возможно, я просто недостаточно знаком с современными конструкциями C++, но часть [&ok]() также требует от меня много размышлений ...

Симпатичная идиома, но не совсем то же самое. возврат в блоке try или catch не пройдет через ваш код 'finally:'.

Этот неправильный ответ (с рейтингом 0) стоит оставить, так как Эдвард Кметт поднимает очень важное различие.

Еще больший недостаток (IMO): этот код съедает все исключения, чего не делает finally.

Управляемые языки нуждаются в finally-блоках именно потому, что автоматически управляется только один вид ресурсов: память. RAII означает, что все ресурсы могут обрабатываться одинаково, поэтому нет необходимости в finally. Если бы вы действительно использовали RAII в своем примере (используя умные указатели в вашем списке вместо голых), код был бы проще, чем ваш «finally» -пример. И еще проще, если вы не проверяете возвращаемое значение new - проверка практически бессмысленна.

new не возвращает NULL, вместо этого выдает исключение

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

C++ 11 улучшает это и включает std::shared_ptr и std::unique_ptr непосредственно в stdlib.

void DoStuff (const vector <string> & input) {список <shared_ptr <Foo>> myList; for (int i = 0; i <input.size (); ++ i) {auto tmp = make_shared <Foo> (input [i]); myList.push_back (tmp); } DoSomething (myList); }

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

Никто не собирается переписывать установленный код, чтобы использовать RAII в полном объеме, даже если они полностью понимают все его нюансы. Блок finally - полезная конструкция, которая позволяет программистам писать более короткий код, который выполняет необходимую очистку ресурсов, не углубляясь в «адские слои-абстракции». Гораздо приятнее - и более читабельно - поймать исключение, что-то с ним сделать, возможно, повторно выбросить и знать, что метод finally всегда будет запускаться за вас, а не устанавливать какие-то флаги в catch {}, освобождать ресурсы, а затем проверять флаги и действующие на них. Ненавижу флаговый суп.

Точно ... RAII кажется хорошим с идеальной точки зрения. Но мне все время приходится работать с обычными C API (например, с функциями C-стиля в Win32 API ...). Очень часто требуется получить ресурс, который возвращает какую-то HANDLE, для очистки которой затем требуется некоторая функция, например CloseHandle (HANDLE). Использование try ... finally - хороший способ справиться с возможными исключениями. (К счастью, похоже, что shared_ptr с настраиваемыми удалителями, а лямбда-выражения C++ 11 должны обеспечивать некоторое облегчение на основе RAII, которое не требует написания целых классов, чтобы обернуть некоторый API, который я использую только в одном месте.).

@JamesJohnston, очень легко написать класс-оболочку, который будет содержать любой дескриптор и обеспечивать механику RAII. Например, ATL предоставляет множество из них. Кажется, вы считаете это слишком большой проблемой, но я не согласен, они очень маленькие и их легко написать.

Просто да, маленькое нет. Размер зависит от сложности библиотеки, с которой вы работаете.

@MarkRansom: есть ли какой-либо механизм, с помощью которого RAII может делать что-то интеллектуальное, если во время очистки возникает исключение, пока еще не обработано другое исключение? В системах с try / finally возможно - хотя и неудобно - организовать все так, чтобы ожидающее исключение и исключение, возникшее во время очистки, сохранялись в новом CleanupFailedException. Есть ли какой-нибудь реальный способ добиться такого результата с помощью RAII?

@supercat, в C++ все еще хуже, исключение, генерируемое во время обработки исключений, может полностью выключить работу. См. c2.com/cgi/wiki?BewareOfExceptionsInTheDestructor

@MarkRansom: Я несколько двояко отношусь к тому, что хуже - подход Java / .net, заключающийся в отказе от существующей инструкции, или подход C++, заключающийся в принудительном отказе системы. Откровенно говоря, я считаю оба подхода довольно ужасными. Однако преимущество finally в том, что если остальная часть блока try написана правильно, код в finally может узнать, ожидает ли исключение. Конечно, если бы язык мог просто предоставить конструкцию finally Exception ex с любым ожидающим исключением (null, если нет), хранящимся в ex, даже этот сценарий был бы намного чище.

@couling: Dispose не имеет ничего общего со сборщиком мусора, а скорее является детерминированным способом уведомления объектов, что их услуги больше не требуются. Наличие явного вызова «очистка при успехе» и наличие метода очистки по умолчанию, предполагающего, что очистка выполняется на предмет ошибки, если часть «успех» не запускалась первой, в некоторой степени работоспособны, но это неприятно, поскольку случайное пропускание части «успех» не может безопасно вызвать исключение (в противном случае это был бы обычный метод уведомления кого-либо о существовании проблемы).

@couling: для ресурсов, которые могут реализовать последовательную семантику «откат, если не зафиксировано», вероятно, было бы разумно, чтобы метод очистки по умолчанию выполнял откат любых незавершенных транзакций. Если пользовательский код случайно забывает фиксацию, последствия будут очевидны. Однако гораздо менее ясно, что следует делать с такими вещами, как файлы общего назначения, где обычная семантика Dispose, как ожидается, будет вести себя по существу так же, как Close. Если Dispose не может генерировать исключения, когда что-то идет не так, его нельзя использовать как обычную «успешную» очистку ...

@couling: ... но не совсем понятно, что еще он должен делать. Для файлов специального назначения можно иметь первую операцию записи, которая изменяет файл, устанавливая в файле флаг «грязный», который сбрасывается только «правильным» Close, но такой подход требует, чтобы класс, реализующий его, знал о том, как флаг грязи и т. д. будет работать (что может быть сложно, если несколько приложений могут получить доступ к разным частям файла одновременно).

@supercat ой, имел в виду finalize, который имеет прямое отношение к GC. Думал не на том языке ... см. Перезапись:

@supercat Интересно, как разные идиомы затрудняют сравнение. пример C++ (на мой взгляд) сопоставим с выбросом RuntimeException на finalize(); эффективно пытается вывести сборщик мусора из строя. Хороший выбор здесь - растопить. В java / .net я считаю, что лучше иметь отдельную «очистку при ошибке» на «очистку при успехе», где я откатываюсь от фиксации и игнорирую (только журнал) против исключения исключения. В результате я теперь наконец все реже и реже пользуюсь. Я считаю, что разработчик ни в коем случае не должен позволять этому «вложенному» исключению влиять на выполнение программы.

@supercat Я понимаю, что написание одного и того же кода дважды таким способом кажется "неприглядным", но мой опыт показывает, что на практике блоки кода "при успехе" и "при ошибке" так часто тонко различаются, что мне редко удается наконец использовать количество утверждений if. Из этих различий наиболее частым является обработка исключений.

@couling: есть много случаев, когда программа вызывает метод SomeObject.DoSomething() и хочет знать, (1) успешно ли он, (2) не удалось без побочных эффектов, (3) не удалось с побочными эффектами, с которыми вызывающий готов справиться, или ( 4) не удалось с побочными эффектами, с которыми вызывающий абонент не может справиться. Только вызывающий будет знать, с какими ситуациями он может и не может справиться; звонящему нужен способ узнать, в какой ситуации. Жаль, что нет стандартного механизма для предоставления наиболее важной информации об исключении.

@couling: Это не должно быть долго. Никто никогда не говорил, что нужно обернуть всю библиотеку. Просто имейте класс MyResource, который инициализирует дескриптор в своем конструкторе, освобождает его в своем деструкторе и имеет класс getHandle(), чтобы вы могли использовать API. Возможно, это не самый приятный вариант, но это RAII для вашей библиотеки C, и он займет максимум ~ 20 строк (это может вызвать больше изменений в вызывающем коде, и если вы думаете, что это слишком многословно, может быть уместно разыменование перегрузки)

Я рад, что вы упомянули, что блок finally может бросить; это то, что большинство ответов «использовать RAII», кажется, игнорируют. Чтобы не писать блок finally дважды, можно сделать что-нибудь вроде std::exception_ptr e; try { /*try block*/ } catch (...) { e = std::current_exception(); } /*finally block*/ if (e) std::rethrow_exception(e);.

Это все, что я хотел знать! Почему ни один из других ответов не объяснил, что ловушка (...) + пустой бросок; работает почти как блок finally? Иногда это просто необходимо.

Решение, которое я предоставил в своем ответе (stackoverflow.com/a/38701485/566849), должно позволять генерировать исключения из блока finally.

Возможная проблема: в функции 'finally (F f)' он возвращает объект FinalAction, поэтому деконструктор может быть вызван перед окончательным возвратом функции. Возможно, нам стоит использовать std :: function вместо шаблона F.

Обратите внимание, что FinalAction в основном совпадает с популярной идиомой ScopeGuard, только с другим именем.

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

Вы потеряете тот факт, что код открытия и закрытия находится рядом, к тому же, если вам нужно написать свой класс, просто используйте RAII.

Насколько безопасна эта оптимизация?

В настоящее время его должны поддерживать все основные компиляторы. Что вас беспокоит?

@ Paolo.Bolzoni Извините, что не ответил раньше, я не получил уведомления о вашем комментарии. Я беспокоился, что блок finally (в котором я вызываю функцию DLL) будет вызываться до конца области (поскольку переменная не используется), но с тех пор я нашел вопрос по SO, который снял мои опасения. Я бы дал ссылку на него, но, к сожалению, больше не могу его найти.

Функция disable () - это своего рода бородавка на вашем чистом дизайне. Если вы хотите, чтобы метод finally вызывался только в случае сбоя, то почему бы просто не использовать оператор catch? Разве это не для этого?

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

Имеет ли смысл удалить метод disable () и вызывать функцию из деструктора только при вызове во время обработки исключения? ~ FinalAction () {если (enabled_ && std :: uncaught_exceptions ()> 0) clean_ (); }

Это не работает, потому что весь смысл блока finally заключается в выполнении очистки, даже если код должен позволяет исключению покинуть блок кода. Подумайте: `try {// что-то, что может бросить" B "} catch (A & a) {} finally {// если бы это было в C++ ... // что-то, что должно произойти, даже если выброшено" B ". } // не будет выполняться, если будет выброшено "B". `IMHO, точка исключений - это код обработки ошибок уменьшать, поэтому блоки catch, где бы ни произошел выброс, контрпродуктивны. Вот почему помогает RAII: при широком применении исключения имеют наибольшее значение на верхнем и нижнем уровнях.

@burlyearly хотя ваше мнение не является святым, я понимаю, но в C++ такого нет, поэтому вы должны рассматривать его как верхний слой, который имитирует это поведение.

DOWNVOTE = ПОЖАЛУЙСТА, КОММЕНТАРИЙ :)

@burlyearly извиняюсь за святое упоминание, позже я узнал, что святое также может означать смирение :)

Привет, я считаю, что мой ответ выше (stackoverflow.com/a/38701485/566849) полностью удовлетворяет вашим требованиям.

Да, это был просто быстрый взлом, но если программист знает, что делает, он тем не менее может быть полезен.

@MarkLakata, я обновил пост, добавив лучшую реализацию, которая поддерживает выдачу исключений и возвратов.

Выглядит хорошо. Вы можете избавиться от Caveat 2, просто вставив невозможный блок catch(xxx) {} в начало макроса finally, где xxx - это фиктивный тип только для того, чтобы иметь хотя бы один блок catch.

@MarkLakata, я тоже думал об этом, но это сделало бы невозможным использование catch(...), не так ли?

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

Gcc выплевывает finally.cpp:60:5: error: ‘...’ handler must be the last handler for its try block. Clang делает то же самое. Я считаю, что стандарт просто запрещает располагать блок catch(...) посередине.

Теперь я понимаю вашу точку зрения (я пропустил ее в первый раз). Может быть, боги С ++ заявили, что этого не должно быть :)