Требуется передать ресурс из std::unique_ptr в C-функцию, которая при успехе принимает владение через сырой указатель. Как обеспечить отсутствие утечки при исключении до успешной передачи?
Передавайте std::unique_ptr в функцию-обёртку по значению, передавайте в C API его сырой указатель, а отказывайтесь от владения только после подтверждённого успеха операции. До этого момента unique_ptr продолжает владеть ресурсом и автоматически освободит его при исключении или ошибке.
Ключевой принцип: вызов release() должен быть последним действием после успешной передачи владения. Если вызвать его раньше, защитник RAII исчезнет, и при исключении или ошибке возникнет утечка.
C-интерфейсы традиционно работают с сырыми указателями и явно описывают правила владения: вызывающая сторона либо сохраняет ресурс, либо передаёт его библиотеке, которая позднее вызывает специальную функцию освобождения. Такой контракт не выражается типом T* и легко нарушается при раннем выходе или исключении.
RAII решает эту проблему на стороне C++: ресурс временно связывается с объектом-владельцем, а освобождение выполняется автоматически. При интеграции с C API необходимо явно обозначить момент перехода владения, чтобы преимущества RAII сохранялись до самого конца операции.
Пусть ресурс создан в std::unique_ptr, а C-функция может вернуть ошибку или косвенно привести к исключению в C++-обёртке. Пока ресурс принадлежит unique_ptr, любой такой путь безопасен: деструктор вызовет назначенный deleter.
Если сначала извлечь сырой указатель и уничтожить владение, а затем вызвать C-функцию, защита RAII будет потеряна. При неудаче ресурс останется без владельца; при ошибочном повторном освобождении возможны двойное освобождение и неопределённое поведение.
Обёртка должна принимать std::unique_ptr по значению. Это явно означает, что она получает владение; вызывающая сторона передаёт его перемещением. До успешного завершения C-вызова локальный unique_ptr остаётся владельцем.
После успешного c_take C API должно однозначно считать ресурс своим и освободить его предусмотренной C-функцией. release() только отключает автоматическое освобождение; он не освобождает ресурс и не передаёт его сам по себе.
Если C API использует специальную функцию уничтожения, исходный unique_ptr до передачи должен иметь совместимый deleter. После подтверждённой передачи deleter unique_ptr уже не вызывается, поэтому C API обязано использовать собственный корректный способ освобождения.
Критически важно, чтобы контракт C-функции был атомарным: при возвращении ошибки она не должна сохранять ресурс, а при успехе должна принять владение. Если функция может частично принять ресурс и затем вернуть ошибку или выбросить исключение через C++-адаптер, одной схемы get() плюс release() недостаточно — нужен отдельный протокол отката или иной API.
Передача по const std::unique_ptr& здесь не подходит: она предоставляет доступ без передачи владения, поэтому C API не должно освобождать такой ресурс. Передача по std::unique_ptr&& также возможна, но требует явного перемещения внутри обёртки; параметр по значению проще отражает факт получения нового владельца.
Обёртка над C-библиотекой регистрировала дескриптор устройства. Разработчик сразу вызывал release(), а затем проверял код возврата регистрации. При ошибке регистрации дескриптор терялся, потому что ни C-библиотека, ни unique_ptr больше не считали себя ответственными за его освобождение.
Рассматривались два варианта. Передача сырого указателя без RAII была простой, но требовала вручную обрабатывать каждый путь выхода. Немедленный release() формально передавал владение, но не защищал от ошибки до завершения регистрации.
Выбранный вариант передавал unique_ptr по значению и вызывал release() только после успешного результата C-функции. При отказе деструктор обёртки освобождал дескриптор, а при успехе дальнейшее освобождение выполняла C-библиотека. Это разделило ответственность по чёткой границе и устранило утечки при исключениях.
Нет, одной проверки недостаточно. Нужно знать точный контракт: при каком результате C API становится владельцем и может ли оно сохранить указатель при ошибке. Если сохранение происходит до возврата, функция должна предоставить способ отмены или вернуть состояние, однозначно определяющее владельца; иначе корректную гарантию исключений построить нельзя.
resource.get(), а затем оставить unique_ptr существовать?Только если C API использует ресурс временно и не становится владельцем. В этом случае unique_ptr продолжает владеть объектом, а C-функция не должна его освобождать или сохранять для последующего использования. Если C API сохраняет указатель, но владение остаётся у unique_ptr, требуется гарантировать, что C API прекратит доступ до уничтожения владельца.
c_destroy, а не delete?unique_ptr должен быть создан с пользовательским deleter, вызывающим c_destroy, пока ресурс находится под управлением C++. Это обеспечивает корректное освобождение при ошибке до передачи. После успешного перехода владения release() отключает этот deleter, и ресурс должен уничтожаться исключительно по правилам C API; смешивать delete и c_destroy нельзя.