C ++ 17에서 std :: make_unique를 사용하는 이유는 무엇입니까?

내가 이해하는 한, C ++ 14 std::make_unique는 매개 변수 평가 순서가 지정되지 않아 안전하지 않았기 때문에 도입되었습니다 .

f(std::unique_ptr<MyClass>(new MyClass(param)), g()); // Syntax A

(설명 : 평가가 먼저 원시 포인터에 대한 메모리를 할당 한 다음 호출 g()하고 std::unique_ptr생성 전에 예외가 throw 되면 메모리가 누출됩니다.)

호출 std::make_unique은 호출 순서를 제한하는 방법이므로 안전을 보장합니다.

f(std::make_unique<MyClass>(param), g());             // Syntax B

: 그 이후로, C ++ (17)는 내 질문에, 그래서 여기, 너무 구문의 안전을, 평가 순서를 명확히했다 사용하는 이유가 여전히 존재 std::make_unique이상 std::unique_ptr++ 17 C에서의 생성자는? 몇 가지 예를 들어 줄 수 있습니까?

현재 내가 상상할 수있는 유일한 이유는 MyClass한 번만 입력 할 수 있다는 것입니다 (를 사용하여 다형성에 의존 할 필요가 없다고 가정 std::unique_ptr<Base>(new Derived(param))). 그러나 그것은 매우 약한 이유처럼 보입니다. 특히 생성자가 std::make_unique하는 동안 deleter를 지정할 수없는 경우 에는 더욱 그렇습니다 std::unique_ptr.

그리고 분명히 std::make_unique말하면 , 나는 표준 라이브러리에서 제거하는 것을지지하는 것이 아니라 (적어도 이전 버전과의 호환성을 위해 타당 함을 유지하는 것이 좋습니다)std::unique_ptr

주된 이유가 제거 된 것이 맞습니다. 여전히 새로운 지침을 사용하지 않으며 타이핑 이유가 적습니다 (유형을 반복하거나 단어를 사용할 필요가 없음 new). 분명히 그것들은 강력한 주장은 아니지만 new내 코드에서 볼 수없는 것을 정말 좋아 합니다.

또한 일관성을 잊지 마십시오. make_shared사용 make_unique은 자연스럽고 패턴에 맞기 때문에 반드시 사용하셔야합니다 . 그것은 변화에 다음 사소한 std::make_unique<MyClass>(param)에 std::make_shared<MyClass>(param)(또는 반대) 구문 A가 훨씬 더 재 작성의 필요합니다.

make_unique구별 T로 T[]하고 T[N], unique_ptr(new ...)하지 않습니다.

당신은 쉽게 된 포인터를 전달하여 정의되지 않은 동작을 얻을 수 있습니다 new[]A와 에드을 unique_ptr<T>, 또는 한 포인터를 전달하여 newA를 에드 unique_ptr<T[]>.

그 이유는 중복없이 짧은 코드를 가지기 때문입니다. 비교

f(std::unique_ptr<MyClass>(new MyClass(param)), g());
f(std::make_unique<MyClass>(param), g());

MyClass, new및 중괄호를 저장 합니다. ptr 과 비교하여 make 에서 한 문자 만 더 비쌉니다 .

모든 사용은 new평생의 정확성을 위해 특별히 신중하게 감사되어야합니다. 삭제 되나요? 한 번만?

의 모든 사용이 make_unique이러한 추가 특성을위한 것은 아닙니다. 소유하는 객체가 "올바른"수명을 갖는 한, 고유 포인터가 "올바른"상태를 유지하도록 재귀 적으로 만듭니다.

이제 unique_ptr<Foo>(new Foo())모든면에서 ¹ 에서 make_unique<Foo>(); " new감사를 위해 모든 용도로 소스 코드를 grep "하면됩니다.

¹ 사실은 일반적인 경우에 거짓말입니다. 완벽한 전달은 완벽하지 않습니다 {}. 기본 init, 배열은 모두 예외입니다.

그 이후로 C ++ 17은 평가 순서를 명확히하여 구문 A도 안전하게 만들었습니다.

정말 충분하지 않습니다. 안전을 보장하기 위해 최근에 도입 된 기술 조항에 의존하는 것은 매우 강력한 관행이 아닙니다.

• 누군가이 코드를 C ++ 14로 컴파일 할 수 있습니다.
• new예를 들어 예제를 복사하여 붙여 넣는 등 다른 곳에서 raw의 사용을 장려 할 수 있습니다 .
• SM이 제안했듯이 코드 중복이 있기 때문에 한 유형은 다른 유형이 변경되지 않고 변경 될 수 있습니다.
• 어떤 종류의 자동 IDE 리팩토링은 그것을 new다른 곳으로 옮길 수 있습니다 .

일반적으로 언어 레이아웃에 의존 하지 않고 표준에서 사소하거나 모호한 기술 조항을 찾지 않고 코드가 적절하고 / 견고하며 / 명확하게 유효한 것은 좋은 생각입니다 .

(이것은 본질적 으로 튜플 파괴의 순서에 대해 여기에서 만든 것과 동일한 주장 입니다.)

void function (std :: unique_ptr (new A ()), std :: unique_ptr (new B ())) {...} 고려

new A ()가 성공했지만 new B ()가 예외를 던진다 고 가정 해보자 : 프로그램의 정상적인 실행을 재개하기 위해이를 포착한다. 불행히도 C ++ 표준은 객체 A가 파괴되고 메모리가 할당 해제 될 것을 요구하지 않습니다. 메모리가 자동으로 누출되고이를 정리할 방법이 없습니다. A와 B를 std :: make_uniques로 래핑하면 누출이 발생하지 않습니다.

void function (std :: make_unique (), std :: make_unique ()) {...} 여기서 요점은 std :: make_unique 및 std :: make_unique가 이제 임시 객체이며 임시 객체 정리가 C ++ 표준 : 소멸자가 트리거되고 메모리가 해제됩니다. 따라서 가능하다면 항상 std :: make_unique 및 std :: make_shared를 사용하여 객체를 할당하는 것을 선호합니다.