这是intrusive_ptr的有效利用? [英] Is this a valid use of intrusive_ptr?

查看:175
本文介绍了这是intrusive_ptr的有效利用?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在我的code我遵循两个规则,当谈到intrusive_ptrs:

Within my code I follow two rules when it comes to intrusive_ptrs:


  • 按值传递的原始指针意味着原始指针是保证该函数的生命周期内有效。

  • 如果原始指针是将被存储及以后的函数的寿命时,它应该被存储在一个intrusive_ptr

很多互联网评论者撰文指出shar​​ed_ptr的应该是pferred超过intrusive_ptr $ P $与第三方code工作时除外。然而,intrusive_ptr省却绕过智能指针,因为你可以从一个原始指针创建intrusive_ptr,当需要超越函数的生命周期的对象。

Many Internet commenters have written that shared_ptr should be preferred over intrusive_ptr except when working with third party code. However, intrusive_ptr obviates passing around smart pointers since you can create an intrusive_ptr from a raw pointer, as when the object is needed beyond the lifetime of the function.

我只是担心,我失去了一些东西,因为什么,我读过取得了这点左右intrusive_ptrs,而大多数人使用的时候似乎preFER shared_ptrs尽管他们的开销也引进问题内存enable_shared_from_this和继承。

I'm just concerned that I'm missing something because nothing that I've read has made this point about intrusive_ptrs, and that most people seem to prefer shared_ptrs even though they introduce memory overhead and also problems when using enable_shared_from_this and inheritance.

推荐答案

这具有所有权语义的公共API中来回传送原始指针应该只很少做的,只有在绝对必要的。例如。与code的界面,你不能改变的接口。

Passing a raw pointer around in a public API that has ownership semantics should be done only rarely, and only when absolutely necessary. E.g. interfacing with code whose interface you can not change.

周围原始指针传递一个私有API,例如一个类的内部成员是没有问题的。

Passing around a raw pointer in a private API, e.g. within the members of a single class is no problem.

考虑以下三个功能:

void f(A* a);
void g(std::unique_ptr<A> a);
void h(std::shared_ptr<A> a);

F的所有权语义不明确。如果你是 F的客户端,你需要阅读文档,如果˚F来找出是要释放 A ,或忽略所有权的问题 A

The ownership semantics of f is not clear. If you are the client of f you need to read the documentation to find out if f is going to deallocate a, or ignore ownership issues for a.

先按g 的所有权语义是明确的。当你调用先按g 你通过 A 先按g 你不再负责。 先按g 要么取消分配的资源其他地方的或转让所有权。

The ownership semantics of g is clear. When you call g you pass the ownership of a to g and you are no longer responsible for it. g will either deallocate a or transfer ownership of that resource somewhere else.

^ h 所有权语义是明确的。当你调用 ^ h ,你和 ^ h A 。最后一个出去关灯。

The ownership semantics of h is clear. When you call h, you and h become co-owners of a. Last one out turns off the lights.

void q(boost::intrusive_ptr<A> a);

具有相同的所有权语义 ^ h 。的主要区别在于以下免费功能必须存在

q has the same ownership semantics as h. The main difference is that the following free functions must exist:

intrusive_ptr_add_ref(A*);
intrusive_ptr_release(A*);

如果您是 F的作者和调用这些函数的 A ,你应该记录你做所以。您的客户不一定会知道你是。而如果你是 F的客户端,你无法知道˚F的办法,除非你看了会调用这些函数其文档。

If you are the author of f and you call these functions on a, you should document that you do so. Your clients won't necessarily know that you are. And if you are a client of f, you have no way of knowing if f will call these functions unless you read its documentation.

如果您是 F的的作者,你打算调用 intrusive_ptr _ * 功能,您可以进行通过编码在你的界面明确代替。

If you are the author of f and you intend on calling the intrusive_ptr_* functions, you can make that explicit in your interface by coding q instead.

但通常没有一个令人信服的理由,强加给 A 来写的作者intrusive_ptr _ * 功能。你可以通过编写 ^ h 代替,得到了相同的所有权语义而不强加的任何 A 进一步的要求。

But usually there is not a compelling reason to impose on the author of A to write the intrusive_ptr_* functions. And you can get the same ownership semantics as q by writing h instead, without imposing any further requirements on A.

在内存开销

如果您创建的shared_ptr

 shared_ptr<A> p = make_shared(arguments-to-construct-an-A);

那么你的的shared_ptr 将拥有完全相同的内存开销为 intrusive_ptr 。实施将分配A与在同一内存分配引用计数。您的客户不需要知道或关心你的的shared_ptr 构建如此有效。

then your shared_ptr will have the exact same memory overhead as an intrusive_ptr. The implementation will allocate the A and the refcount in the same memory allocation. Your clients need not know or care that your shared_ptr was constructed so efficiently.

这篇关于这是intrusive_ptr的有效利用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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