나는 std::unique_ptr 및 다른 원시 포인터가 있습니다. 원시 포인터가 어떤 종류의 소유권없이 unique_ptr의 내용을 가리 키기를 원합니다. 읽기 전용 관계입니다 :std :: unique_ptr의 내용 가리키는
auto bar=std::make_unique<foo>();
auto ptr=bar.get();// This may point to another value later
이것은 나빴습니까? 어떤 대안이 있습니까?
참고 : 실제 예제는 더 복잡합니다. 그들은 같은 계급에 있지 않습니다.
은, 다음이 완벽하게 정상적으로이며, 아마도 소유권없이 포인터를 전달해야하는 상황에 이상적입니다.
이러한 두 가지 조건을 보장 할 수없는 경우 std::shared_ptr 및 std::weak_ptr을 사용해야합니다.
그리고 아마도'shared_ptr'을 사용하지 말아야합니다. 왜냐하면 99 %의 "shared_ptr"로 자원 문제를 해결할 수 있기 때문에 나쁜 생각이 들기 때문입니다. – Yakk
@Yakk 기껏해야, 나는 그 쌍곡선을, 그리고 최악의 경우 순진하다고 부를 것이다. 가장 좋은, 가장 관용적 인 해결책이'std :: shared_ptr'의 사용을 불러 일으킨 C++ 토지에서 많은 문제를 겪었습니다. 처음에는 포인터에 대한 의존도가 디자인 복잡성의 원인 (또는 증상)을 나타내는 경향이 있지만 '99 %의 시간'이 잘못되면 Java (기본적으로'shared_ptr'와 유사한 객체를 사용함) 모든 포인터에 대해) 언어로서 사용할 수 없으며, 우리는 그렇지 않다는 것을 압니다. – Xirema
우리는 그것을 정말로 알고 있습니까? 하지만 진지하게, Java는 rc 포인터와 다른 짐승 인 full gc 포인터를 사용합니다. rc 포인터를 실제 gc 포인터의 일종으로 생각하면 구성 요소의 설계에 근본적인 오류가 있음을 알 수 있으며 그러한 오류는 99 %의 일부입니다. 나는 공유 포인터가 옳은 상황을 발견했다. (실제로 포인터 문제를 여기저기서 생각하지 않으려 고하는 것이 아닌, 일부 자원에 대한 실제 * 공유 소유권이있을 때), 흔히 볼 수있는 일생 문제 공유 된 포인터와 약점을 시스템에 단순히 삽으로써 해결할 수 있습니다. – Yakk
아니오, 표준 라이브러리에 proposed std::observer_ptr이 포함될 때까지 소유주가 아닌 관찰자를 표현하는 관용적 방식입니다. 당신이bar의 수명이 더 프로그래머/리팩토링은 과거의 어떤 시점에서 delete ptr;을 쓸 것)을 ptr의 수명을 초과, 그리고 B 것이다) 그 을 보장 할 수있는 경우
그리고 그 후에도 그것을 표현하는 관용적 인 방법이 될 것입니다. Core C++ 지침은'observer_ptr'을 사용한다고 말하지 않습니다; 그들은 모든 알몸'T *'가 비 소유권을 대표한다고 말한다. –
@NicolBolas'std :: experimental :: observer_ptr'이'std :: observer_ptr'가 된 후에도 여전히 그렇게 말할 수 있을지는 의문입니다. 지침을 "T *"를 비 소유권으로 읽는 것으로 상상할 수 있지만 소유권을'std :: observer_ptr
"*'std :: experimental :: observer_ptr'이'std :: observer_ptr'가 된 후에도 여전히 그렇게 말할 수 있을지는 의문입니다. *"그리고 그것은 실제로 일어날 지 여부에 대한 질문입니다. TS가 제안되고 핵심 표준에 채택되는 사이의 변화. 또한, 그것은 마술처럼 포인터를 소유하지 않은 경우에 알몸 포인터를 사용하는 기존 C++ 코드 라인의 수십억 개를 변형시키지 않습니다. –
'bar.get();'이 아니어야합니까? –
@ πάνταῥεῖ 예 죄송합니다. –
나는 이것이 이상적이라고 말하고 싶습니다. 그러나 이미 다른 의미를 가진'std :: weak_ptr'가 있기 때문에 아마 다른 이름을 선택할 것입니다. – Galik