Jody Hagins wrote:

Umm... not trying to start a war or anything, but please do not do that. Personally, I do not like the threading policy of shared_ptr. I use it, but I really do not like it. In general, the Boost preference seems to be compiled code is either multithread enabled or not (i.e., object are different sizes based on compile time macros).

In my experience, I have found making the thread policy an actual policy (similar to how ACE does it) better. It allows me to compile/link different policies, depending on how they are used.

For example, if I have a multi-threaded application, Boost classes require me to use all multithreaded support. However, my main thread may be tight, and use shared_ptr objects that do not span multiple threads. In that case, I'd like to use something like shared_ptr< Foo, Noop_Lock_Policy > for stuff I know is OK without locking...

This is precisely what I was describing for the way that Loki does it. Basically every class can support threading or not via its policy. I agree that this is more flexible and preferable in many circumstances to the boost.shared_ptr method. Dave Handley