指向std :: unique_ptr的内容

我有一个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

这是坏的吗？有其他选择吗？

注意：真正的例子是更复杂的。他们不在同一班。

来源

2016-08-11 Humam Helfawi

不应该是'bar.get（）;'？ –

@πάνταῥεῖ对不起 –

我会说这是理想的。但是我可能会选择一个不同的名字，因为已经有一个具有不同语义的'std :: weak_ptr'。 – Galik

如果你能保证A）bar的寿命将超过ptr的寿命，以及B）没有程序员/重构将永远写delete ptr;在任何时候，那么这是完全正常的，并可能是适用于任何需要传递无需拥有所有指针的情况。

如果这两个条件不能保证，您应该使用std::shared_ptr和std::weak_ptr。

来源

2016-08-11 16:38:31 Xirema

你可能不应该使用'shared_ptr'，因为99％的“等待，我可以用'shared_ptr'解决我的资源问题”最终不是个好主意。 – Yakk

@Yakk充其量，我会称之为双曲线，最坏的情况是天真的。我在C++领域遇到了很多问题，其中最好的，最常用的解决方案调用了'std :: shared_ptr'。我会告诉你，首先对指针的依赖倾向于代表设计复杂性的原因（或症状），但如果它们在'99％的时间内'不好，Java（基本上使用'shared_ptr'-like objects所有的指针）将作为一种语言无法使用，我们知道情况并非如此。 – Xirema

我们真的知道吗？但是，严重的是，Java使用完整的gc指针，这与rc指针不同。把rc指针看作某种真正的gc指针是组件设计中一个根本性错误的标志，而这种错误是99％的一部分。我发现共享指针是正确的（当你拥有某些资源的实际*共享所有权时，不仅仅是“我不想在这里考虑指向指针的问题”），但很少能够使用一般的拥有观察生存期问题只需将共享和弱点指向系统即可解决。 – Yakk

不，这并不坏，直到标准库合并proposed std::observer_ptr，它是表达非拥有观察员的地道方式。

来源

2016-08-11 16:38:12 Angew

即使在那之后，它也将是表达这种习惯的惯用方式。 Core C++的指导方针并没有说使用'observer_ptr';他们说所有裸体的T *代表非所有权。 –

@NicolBolas这是一个问题，他们是否仍然会说'std :: experimental :: observer_ptr'成为'std :: observer_ptr'后。我可以想象这个指导方针转变为“读取T *'为非所有权，但是将非所有权写为'std :: observer_ptr '。”。 – Angew

“*这是一个问题，他们是否仍然会说'std :: experimental :: observer_ptr'成为'std :: observer_ptr'。”之后，这是否会实际发生？ TS在被提出和被采用到核心标准之间的变化。此外，这不会神奇地转换使用裸指针取代指针的现有C++代码的数十亿行。 –

指向std :: unique_ptr的内容

回答

相关问题