`std::make_shared`가 `std::shared_ptr`을 직접 생성하는 것보다 더 효율적인가요?

std::make_shared의 효율성

std::make_shared 함수를 사용하여 원시 포인터에서 공유 포인터를 설계할 때 차이점이 있습니다. 생성자를 사용하여 std::shared_ptr을 직접 생성하는 것과 비교할 때 효율성이 높습니다. 단계별 설명은 다음과 같습니다.

std::make_shared:

1. 참조 카운팅 및 기타 메타데이터를 관리하는 제어 블록 모두에 메모리를 할당합니다. ) 및 객체.
2. 할당된 std::shared_ptr 객체를 구성합니다. memory.

직접 std::shared_ptr 생성자:

1. new를 사용하여 객체에 메모리를 할당합니다.
2. 객체에 메모리를 할당합니다. 제어 블록을 구성합니다.
3. std::shared_ptr 객체에 할당된 메모리가 있습니다.

보시다시피 std::make_shared는 (제어 블록과 객체 모두에 대해) 단일 할당을 수행하는 반면 직접 생성자 메서드는 두 가지 할당을 수행합니다. 할당(객체용 하나, 제어 블록용 하나) 할당의 이러한 차이는 std::make_shared를 사용할 때 더 큰 효율성으로 이어집니다.

예외 안전성

C 17 이전에는 std::make_shared를 사용하는 것도 더 많은 예외였습니다. 안전한. 다음 코드를 고려하십시오.

void f(const std::shared_ptr<Object1>& obj1, const std::shared_ptr<Object2>& obj2) {
  // ...
}

int main() {
  f(std::shared_ptr<Object1>(new Object1()), std::shared_ptr<Object2>(new Object2()));
  return 0;
}

std::make_shared가 없으면 인수 평가 순서가 지정되지 않으며 Object1 할당이 실패하면 Object2의 메모리가 누수됩니다. std::make_shared를 사용하면 이 예외 안전성 문제가 해결됩니다.

std::make_shared의 단점

std::make_shared의 한 가지 잠재적인 단점은 객체 메모리의 조기 할당 해제를 방지합니다. 직접 생성자 방법과 달리 std::make_shared는 제어 블록과 객체에 대한 단일 메모리 블록을 생성합니다. 이는 개체와 제어 블록 모두에 대한 메모리를 독립적으로 할당 해제할 수 없음을 의미합니다. 객체를 가리키는 약한 포인터가 있는 경우 객체 자체가 더 이상 사용되지 않은 후에도 제어 블록을 활성 상태로 유지할 수 있어 잠재적으로 메모리 보존이 발생할 수 있습니다.

위 내용은 `std::make_shared`가 `std::shared_ptr`을 직접 생성하는 것보다 더 효율적인가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!