Может произойти сбой инициализации unique_ptr & lt; & gt; ()?

Из документации станд :: unique_ptr<> (), что может произойти при инициализации указателя мне не понятно.

При выделении std::shared_ptr<>(), он выделяет буфер памяти для обработки счетчика ссылок. Так что я могу получить std::bad_alloc исключение.

Может ли нечто подобное произойти при инициализации уникального указателя?

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

void deleter(FILE * f)
{
fclose(f);
}

void func()
{
...
FILE * f(fopen("/tmp/random", O_CREAT | ...));
if(f == nullptr) ...handle error...
std::unique_ptr<FILE, decltype(&deleter)> raii_file(f, deleter);
...
}

Итак, если инициализация unique_ptr<>() может бросить, я могу в конечном итоге сохранить файл f открыть навсегда. (Я использую FILE * В качестве примера, любой подобный ресурс может быть затронут.)

В противоположность этот ответ, Я явно не могу использовать std::make_unique<>() так как я не просто выделяю память.

Будет ли безопаснее инициализировать std::unique_ptr<>() перед fopen(), а затем сохранить значение там после?

  ...
std::unique_ptr<FILE, decltype(&deleter)> raii_file(nullptr, deleter);
FILE * f(fopen("/tmp/random", O_CREAT | ...));
if(f == nullptr) ...handle error...
raii_file = f;
...

Или у этого были бы подобные проблемы?

0

Решение

Все unique_ptrконструкторы noexcept, Так что нет, это никак не может сорваться. Если твой Deleter Тип бросает при копировании / перемещении, затем noexcept поймаю и позвоню std::terminate,

4

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]