Eric Niebler wrote:
I'm thinking about replacing some uses of shared_ptr with intrusive_ptr, but I've got questions. One of the nice things about shared_ptr is the lock-free thread-safe ref counting. I want my intrusive_ptr to have the same safety and efficiency, but I don't see how to get it. I see $boost_root/detail/atomic_count.hpp, but shared_ptr doesn't use it. Why not? And why is it in detail/? Should I not consider using it?
shared_ptr doesn't use atomic_count because the addition of weak_ptr has made atomic_count's interface insufficient. atomic_count is in detail:: because I didn't consider it ready for boost::. On the other hand, if it works for you, there is no reason to not use it.
Taking in the bigger picture, intrusive_ptr requires people to write their own add_ref and release functions, most of which will probably end up using ++ and -- on a plain integer. This is totally broken in multi-threaded applications, right?
Using ++ and -- on a plain integer without synchronization is broken in MT apps, yes.
Isn't it dangerous to not provide complementary utilities for correctly managing reference counts? It seems to me intrusive_ptr is impossible to use safely and portably. What have I missed?
It's possible to use intrusive_ptr safely and portably if you already have an existing library that provides intrusive reference counting without also supplying a corresponding pointer type, and one of the goals of boost::intrusive_ptr is to establish a standard "corresponding pointer type" for such libraries. However, you are right that intrusive_ptr doesn't help the implementers of these libraries to get their reference counting correct, and that it probably should do that.