Question

我在我的应用程序设计中使用了shared_ptr，并且我倾向于越来越多的对象变成堆分配而不是堆栈上的简单对象（或者更复杂的对象）。而不是简单（但有风险，Foo :: bar将在更复杂的情况下成为悬挂参考）...

struct Bar { };
struct Foo { Foo(Bar& bar) : bar(bar) { }; Bar& bar; };
int main() {
  Bar bar;
  Foo foo(bar);
  // ...
}

... 我需要去做 ...

struct Bar { };
struct Foo { Foo(shared_ptr bar) : bar(bar) { }; shared_ptr<Bar> bar; };
int main() {
  shared_ptr<Bar> bar = make_shared<Bar>();
  Foo foo(bar);
  // ...
}

...因为我想避免手动对象终身跟踪
我是否错过了shared_ptr使用中的点，或者这是自动终身管理的费用？或者这可能是糟糕的设计标志？

Answer 1

这是你的物体生命周期的问题。当您真正在多个其他对象之间共享对象时，应该使用shared_ptr。

在您的情况下，FOO和BAR的所有者必须控制两者的生命周期。也许有可能让BAR成为你FOO级别的私人成员，让FOO控制生命周期。

我个人使用智能指针来表达对象的所有权。 Shared_ptr意味着它真的是共享的，我不是这个对象的唯一所有者。 Scoped或唯一指针显示我是该对象的唯一所有者。如果要转移所有权，可以使用auto_ptr或C ++ 0x移动语义。

至少在较大的项目中，我看到缺乏生命周期控制会导致悬挂物体。因此，由于自动生命周期管理，您不再有直接内存泄漏，但是您获得了循环依赖性。这导致了同样的结果。

如果这是一个糟糕的设计，请回答你的问题。这取决于你在做什么。

Answer 2

这是糟糕设计的标志。当您的对象必须堆分配时，存在shared_ptr。你永远不应该在堆上分配任何东西，因为你可以使用shared_ptr。堆栈仍然是英里的最佳选择。

在开始决定如何实现它之前，需要知道什么，需要在堆上运行哪些对象以及哪些需要进入堆栈，以及所有权是什么。然后，您可以使用shared_ptr作为实施工具。

Answer 3

您是否尝试过使用值而不是指针？

基于shared_ptr的设计问题

3 个答案: