Shared_ptr will only include threading support in a multithreaded environment. So you only pay for it if there is a possibility of shared_ptr's being shared across threads.
The problem with letting the developer decide on a per ptr basis whether or not they need MT support is that users (myself included of course) tend to make poor choices. Also code changes, a design which didn't share ptr objects across threads may well end up sharing ptr objects as the code matures/is maintained.
I beg to differ. I don't make poor choices on a per-pointer basis. <heh> We typically use single-threaded policy-pointers in multi-threaded apps when we need the performance and know that the objects we're handling are either safely tucked away in that operating thread, or can be deep-copied across threads using some external synchronization. If you have a policy-based smart pointer and are concerned that developers should not have equal access to ST and MT versions, consider making a default version that is MT, and leaving it at that. As far as the code changing and shared objects being passed across threads, if you don't understand the ramifications of the design changes you are making, you get what you deserve. Just because you're passing shared, lockable objects acrosss threads doesn't mean you couldn't get into a deadlock situation, for example.
For myself, I would want MT support built in by default. Its too easy to get wrong to disable it for performance reasons. And I don't buy that a smart pointer has to be the most efficient thing in the world, how many apps have smart pointer usage as their bottleneck?
Mine. Tested and found with Quantify, and although it was our own policy-based smart pointer, the mutex locking was the high peak on the graph. I halved my app's response latency by using a single-threaded smart pointer in a multi-threaded app. I'm not weighing in for support of the proposed code, I'm simply stating that I think having access to a shared ST pointer is a good idea in an MT environment. And personally I'd prefer a declaration of the policies required instead of a macro to change the behavior of specific class. - Bud