At 09:00 PM 8/10/2008, you wrote:

On Sun, Aug 10, 2008 at 9:47 AM, Alan M. Carroll wrote:

...

I greatly prefer intrusive_ptr to shared_ptr, but one drawback of that is there is no equivalent of weak_ptr. I have started work on a class to do that and my biggest question, honestly, was what to name it.

Have you considered the allocator support in shared_ptr? It makes it possible to allocate the control block in the same memory block as the managed object. Between this and the aliasing support in shared_ptr, I've found intrusive_ptr's use rather limited.

I haven't really consider the shared_ptr allocator support. I use primarily intrusive_ptr for historical and implementation reasons. I started using intrusive pointers over a decade ago (my own version at first, later Boost, when it became available). Back then shared_ptr had a much poorer and less usable interface (IIRC, it didn't support casting very well which was a big thing for me). I have long since built support classes to make use of intrusive_ptr very simple, just a 1 line inherit, plus the personal familiarity. Asking why I don't use shared_ptr and its allocator support is effectively asking "why don't you got to a lot of effort to get the same functionality you have now?". Not to disparage shared_ptr, but that's just not an attractive option for me. I might view it differently if I were a newbie, but I'm not, so there it is. Implementing my own intrusive_weak_ptr was less work overall *for me* than switching to shared_ptr. Moreover, shared_ptr doesn't solve the issue that is most important to me, safe conversion to and from raw pointers. This shows up in a couple of places 1) Self registration. 2) Handle from this. 3) Some other very esoteric places that I haven't the energy to go in to and no one else would find interesting. Yes, there are work arounds for shared_ptr, but why not just solve it up front with intrusive_ptr? If, as the flip side of me, you use shared_ptr everywhere else and this doesn't come up much, sure. But my situation is the other way around. Boost takes the right approach, in that it adapts to the peculiarities of the client, it doesn't force the client to adapt to Boost's peculiarities.