创建shared_ptr来堆叠对象 [英] Create shared_ptr to stack object

查看:98
本文介绍了创建shared_ptr来堆叠对象的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在我的方法中,创建了一个Player对象,如下所示:

In my method a Player object is created like:

Player player(fullName,age);

我的老师给了我们一段代码,其中包含一个将shared_ptr用作播放器对象的构造函数。 / p>

My teacher gave us a piece of code with a constructor that takes a shared_ptr to a player object.

//constructor of the class
SomeClass(const std::shared_ptr<Socket> client, std::shared_ptr<Player> player)

让我们说我们想调用SomeClass的构造函数并传递我们创建的播放器对象

Lets say we want to call the constructor of SomeClass and pass the player object we created on stack.

从堆栈对象创建shared_ptr是否安全/可行/良好?

Is it ever safe/possible/good to create a shared_ptr from a stack object?

为了使问题更易于理解,可以说我们有两个大型代码项目,并且我们希望将它们合并,因此应该重写所有文件以使用shared_ptr或堆栈对象(对于这些方法,

To make the question more understandable lets say we have two big code projects and we want to merge them so a method from one project is called from another one, should we rewrite all the files to use shared_ptr or stack objects exclusivly (for the methods that needs to be connected) or should we just create a shared_ptr to the stack object.

为什么我不确定结果呢?

如果在创建堆栈对象的范围内会怎样结束,但仍然使用shared_ptr,反之亦然。

What if the scope where the stackobject is created ends but the shared_ptr is still used and vise versa.

当超出范围时,stackobject将被删除,或者由于仍然有对该对象的引用,它会保持活动状态

The stackobject gets deleted when out of scope or does it stay alive because there is still a reference to the object (in another class though)?

shared_ptr超出范围并尝试删除该对象,即使stackobject引用了它也可以吗?

The shared_ptr goes out of scope and tries to delete the object, can it even though the stackobject is refering to it?

注意:我知道我可以使用以下选项并通过播放器

shared_ptr<Player> player{ new Player {fullName,age} };


推荐答案


是否安全? / possible / good可以从堆栈对象创建smart_ptr?

Is it ever safe/possible/good to create a smart_ptr from a stack object?

安全?仅当您可以保证时,创建该对象的堆栈才会在所有 shared_ptr 都是其伪拥有者之后才结束。

Safe? Only if you can guarantee that the stack which created that object will only be ended after all shared_ptr's that pseudo-own it.

可能?当然:将 shared_ptr 的构造函数传递给不执行任何操作的删除对象:

Possible? Sure: pass shared_ptr's constructor a deleter object that does nothing:

auto sptr = shared_ptr<Player>(&player, [](Player *) {});

最后一个 shared_ptr 被销毁时,

?并不是的。如上所述,在这种代码中不能普遍保证安全性。根据您的代码结构,这可能是合法的。

Good? Not really. As noted above, safety is not something that can be universally guaranteed in such code. Depending on your code structure, this may be legitimate. But it requires great care.

这个 SomeClass 期望对资源拥有所有权。这就是为什么要使用 shared_ptr 的原因。您可能会向它传递一个 shared_ptr ,但它并不真正拥有它所引用的对象。这意味着您有责任,并且您的代码结构不会违反您对 SomeClass 所作的承诺,即它将共享控制该对象的生存期。

This SomeClass is expecting to claim ownership of a resource; that's why it's taking a shared_ptr. You're kind of lying to it by passing it a shared_ptr that doesn't really own the object it references. That means the onus is on you and your code structure to not violate the promise you made to SomeClass that it would have shared control over that object's lifetime.

这篇关于创建shared_ptr来堆叠对象的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆