问题标签 [ownership-semantics]

我有以下情况：有GraphicsContext类：

还有一类应用程序使用了 GraphicsContext：

并且有一些在 Application 类中使用的子级类，以及那些使用 GraphicsContext 中的 Renderer 的子级类。我需要在这些类中存储指向渲染器的指针，但我应该怎么做呢？

这样的子级类在语义上并不拥有渲染器，因此我认为使用 shared_ptr 而不是 unique_ptr 并不是一个好主意。但是，如果保证子级类的对象比 Application 对象的生存时间短，如何组织这种所有权呢？我可以存储并从 GraphicsContext 返回指向 Renderer 的原始指针还是语义错误的想法？

我有一个函数，其中回调接收一个event持有 unique_ptr 实例的data. char*我可以通过它来检索event.data.get()应该给我指针而不是所有权，从而允许对象自由删除它。现在我有另一个函数，它接受一个 unique_ptr 实例，otherdata当然管理所有权，所以该函数可以自由地释放它。所以我试图data从回调中获取并将其传递给安全的函数otherdata。

上面的示例似乎确实有效，但我不确定这是否是正确的方法。事件是否放弃所有权？如果是这样，放弃所有权是否安全？

为什么这会导致编译器错误：Call to implicitly-deleted copy constructor of 'std::unique_ptr<char []>'？

如果 event.data 给我一个 unique_ptr 并且 stream.write 需要一个 unique_ptr 那么上面的代码不应该正常工作吗？或这个

抱歉，我的 C++ 知识非常有限，所以 unique_ptr 和 move 语义非常混乱。

Consider a Foo that holds some resource

and a global std::vector<Foo>. Perhaps stupid example, but it illustrates the problem well.

std::vector<Foo> bar;

Now, the processes forks.

If bar is then only modified by the child process, then a call to exit should be the proper thing to do within the child process. If calling _exit, any Foo:s in bar would leak. If the parent added some stuff to bar before the fork, these object may be destroyed twice. Or maybe this is not a problem, because they should be considered as different objects.

What is the proper way of dealing with object lifetime together with a fork. Is the only sane way of dealing with this problems to let the child exec and start over?

I should notice that at this point in the program, there is guaranteed to be only one thread.

我知道std::unique_ptr当一个对象只有一个所有者并且std::shared_ptr当一个对象有多个所有者时使用它。成为对象的唯一所有者意味着什么？

作为唯一的所有者是否意味着没有其他人可以看到该对象？

get()将指针作为引用传递时，我可以使用该方法返回原始指针吗？

我觉得如果我必须使用get()，那么我要么通过 using 转移所有权std::move，要么使用共享指针。

仅考虑可移动但不可复制的对象（例如，std::thread或std::unique_ptr），我想通过将其作为参数传递给构造函数来转移此类对象包含的资源的所有权。我正在比较两种方法：构造函数按值获取对象与按右值引用获取对象。

作为 的示例std::thread，请考虑以下类Value，其构造函数采用std::thread by value：

所有权从参数对象转移到参数对象，th最后转移到数据成员对象，th_。

考虑一个类似的类 ，Reference它的构造函数在这种情况下std::thread采用右值引用：

在这种情况下，所有权从参数直接转移到数据成员对象th_.

据我了解，在按值传递的情况下，参数对象和数据成员对象都是移动构造的，而对于按引用传递的情况，只有数据成员是移动构造的。总而言之，后一种方法似乎更好，因为它只需要一次移动操作，因此效率更高。

但是，是否有任何理由更喜欢按值传递的方法而不是按引用传递的方法？

我对以下行为感到困惑：有人可以解释发生了什么吗？

考虑代码：

具体来说，我很困惑：

1. 即使发生了移动，也允许更新到，p1.cx
2. 返回的值p2.x实际上不是更新后的 5000，而是旧的100.

我期待新值，因为没有复制特征（因此移动），所以期待只有一个单元格的更新值（5000）应该被打印。

但是，我一定错过了什么。有小费吗？提前致谢！

在使用 C++ 智能指针（唯一、共享、弱）时，有两个概念（所有权、生命周期）很重要。我试图理解这些概念以及它们如何影响智能指针（或原始指针）的使用。

我读了两条规则：

1. 始终使用智能指针来管理动态对象的所有权/生命周期。
2. 在不管理所有权/生命周期时不要使用智能指针。

一个例子：

我想用智能指针重写它。让我们先忽略 child()。轻松的游戏。父母拥有自己的孩子。所以让 mChildren 成为 unique_ptr 的向量。

根据上述规则，有些人认为 child(i) 应该继续返回原始指针。

但这不是有风险吗？有人可能会做一些愚蠢的事情，比如删除返回的对象会导致难以调试的崩溃……这可以通过使用 weak_ptr 或 shared_ptr 作为返回值来避免。

不能说复制指针总是意味着暂时共享所有权和/或断言对象的生命周期吗？

仅当我没有获得更安全的 API 时才值得为儿童使用智能指针吗？

我的心态是让我String的 s 保持不变，一个单一的事实来源。当我将同样的心态带入 Rust 时，我发现我必须做很多克隆。由于Strings 没有改变，所有的克隆都是不必要的。下面有一个例子和相关游乐场的链接。

借用似乎不是一种选择，因为我必须处理引用及其生命周期。我的下一个想法是使用类似Rc或Cow结构的东西。但是用类似的东西包裹所有的StringsRc感觉不自然。在我有限的 Rust 经验中，我从未见过任何暴露的所有权/内存管理结构，即Rcand Cow. 我很好奇一个更有经验的 Rust 开发人员会如何处理这样的问题。

Rc在 Rust 中公开所有权/内存管理结构，比如and是否真的很自然Cow？我应该使用切片吗？

为什么 Rust 不能完全推断其变量的所有权？为什么需要注释？

当 refcount = 0 时，调用 __destruct 魔术方法。有没有办法捕捉到 refcount 减少或增加但不是零的事实？

这种事件的一个用例是检测对象是共享的（refcount > 1）还是拥有的（refcount = 1）。

编辑：好像没有。一个可能的解决方案是在 PHP 中添加两个新的魔法方法：__owned 和 __shared。当 refcount = 0（销毁）、refcount = 1（拥有）和 refcount > 1（共享）时，我们会有方法。我将讨论 PHP 内部。