Don G wrote: [...]
The std containers offer what is needed to accomplish a well focused task, allocating only the data necessary for that job and no more. For example std::list need only allocate 2 pointers per object. If Stepanov had gone on to add feature after feature that made this number on par with shared_ptr, again, it likely would not have been well received.
... and ...
I am focused on the last statement above. As it sits, shared_ptr simply goes too far and in so doing one must always ask "is shared_ptr suitable in this case?" As a library author, this is often an impossible question to answer, because it could depend on the use to which the library is put. In other words, by adding all the frills, shared_ptr actually reduces its scope of applicability.
... and ...
"WARNING: shared_ptr may allocate 40+ bytes per object (fine print: depending on platform and multithread considerations, your mileage may vary, etc.)"
shared_ptr only contains the features that are absolutely essential for the answer of "is shared_ptr suitable" to be "yes" in the vast majority of cases (and to stay "yes" as the design evolves). A not so small number of extra features that do not contribute significantly to its expressive power have been rejected. I suspect that you haven't had much experience with the design possibilities opened by weak pointers or custom deleters, which might be why you don't want to pay 40+ bytes for them. For me, they are easily worth double this cost. That said, Alexander Terekhov has discovered a lock-free algorithm that implements the reference counting required by shared_ptr, so this brings down the design-imposed overhead to four words per object for an empty deleter. You can find a prototype implementation at http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp I will try to portabilify this implementation and incorporate it in the next Boost release. You are absolutely correct that sometimes you can get away with a simpler smart pointer that carries less overhead. The emphasis in shared_ptr's case is on correctness and expressive power over efficiency, because (IMO) the first two provide more value in a standard smart pointer, since they are much more harder to reinvent. The good thing is that once you have a stable design, efficiency usually follows, as happened here.