挺多限制

在sharedptr能被隐藏起来,不需要对外转成sharedptr

并且保证业务逻辑保证不会循环引用

并且在乎sharedptr 因为集成dtor和weak counter的overhead

总的来说，极少

【 在 DoorWay 的大作中提到: 】
: 引用计数RefCountPtr 配合 RefCountBase多？

- 来自「最水木 for iPhone12,8」
--
FROM 104.133.8.*

现在的代码库，用的是后者，自己实现的引用计数对象，
RefCountPtr 配合 RefCountBase。审代码发如下：

RefCountPtr<T> ptrT = T::Create();
auto p = ptrT.get();
RefCountPtr<T> ptrT2(p);

我一直用stl的实现，所以第一反应典型会double free。
但并不会。第三句还是将引用计数升为2了。因为计数在T对象内。

觉得很有意思。这是引用计数对象设计原始目标之一，还是意外的好处？

【 在 lambdai 的大作中提到: 】
: 挺多限制
: 在sharedptr能被隐藏起来,不需要对外转成sharedptr
: 并且保证业务逻辑保证不会循环引用
: ...................
--
FROM 117.39.231.*

hmm，这个RefCountPtr是个很有名的类吗？是哪里面实现的？

你说的这个是不是T 继承 RefCountPtr<T>的样子？这样对T有侵入，那确实不会double free



【 在 DoorWay 的大作中提到: 】
: 现在的代码库，用的是后者，自己实现的引用计数对象，
: RefCountPtr 配合 RefCountBase。审代码发如下：
:
: ....................

- 来自「最水木 for iPhone12,8」
--
FROM 104.133.9.*

自己造轮子一般都是Cpp11之前的库，比如著名的opencv。
如果你能使用11，就不要自己造轮子了。

【 在 DoorWay 的大作中提到: 】
: 好的。我是想问，第三条路，自己实现引用计数对象的多吗？
: 还是stl unique 以前的探索。11以后就不用了？
: 【 在 foliver 的大作中提到: 】
: ...................
--来自微水木3.5.11
--
FROM 39.144.44.*

智能对象基类好处是？
【 在 boosted 的大作中提到: 】
: 都用。如果header only 用shared_ptr的多，如果要搞大库，还得自己弄智能对象基类。
:
--
FROM 117.39.231.*