unique_ptr <>() 초기화가 실패 할 수 있습니까?

Question

std::unique_ptr<>()의 문서에서 포인터 초기화가 나에게 명확하지 않을 때 어떤 일이 발생할 수 있습니다.

std::shared_ptr<>()을 할당 할 때 메모리 버퍼를 할당하여 참조 카운터를 처리합니다. 그래서 std::bad_alloc 예외가 발생할 수 있습니다.

고유 포인터를 초기화 할 때 비슷한 일이 발생할 수 있습니까?

나는 그것이 고유 포인터를 통해 삭제하려고 시도했던 것을 실제로 잃어 버릴 수 있기 때문에 질문하고 있습니다. 예를 들어 : unique_ptr<>()의 초기화가 던질 수있는 경우

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); 
    ... 
} 

그래서, 나는 열린 f 영원히 파일을 유지 끝낼 수 있습니다. (예를 들어, FILE *을 사용하면 비슷한 리소스가 영향을받을 수 있습니다.)

this answer과 대립하면 메모리를 할당하는 것이 아니기 때문에 분명히 std::make_unique<>()을 사용할 수 없습니다.

fopen() 전에 std::unique_ptr<>()을 초기화 한 다음 그 값을 저장하는 것이 더 안전할까요?

... 
    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; 
    ... 

아니면 비슷한 문제가 있습니까?

Answer 1

unique_ptr의 생성자는 모두 noexcept입니다. 그래서 실패 할 수있는 방법이 없습니다. Deleter 유형이 복사/이동 중에 발생하면 noexcept이이를 catch하고 std::terminate으로 전화합니다.