Pavel Vasiliev wrote:

Andrei, please don't take me wrong. I felt myself inspired after
reading your Modern C++ Design and some articles in CUJ. But I'm
also completely agree with rationale given in QA1-3 at
http://www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ

Q. I am not convinced. Default parameters can be used where appropriate to hide the complexity. Again, why not policies?
A. Template parameters affect the type. See the answer to the first question above.

I don't get this argument. Isn't that exactly what you want. You wouldn't want people mixing different types smart pointers. And you definitely don't want people doing things like:

smart_ptr<x> one;
smart_ptr<y> two;

one = two;

Changing T changes the type, how is that different than a secondary template parameter? And if we're talking complexity, why isn't anyone seeking to remove traits based iterators from a container classes. Iterators are pretty hard to create on your own. Creating iterator classes is something I rarely do, though, just as I expect I'd rarely create my own smart pointer traits class. But when I do, it's nice to have the facility and people seem to use iterators fairly effectively.

Q. Why doesn't shared_ptr have template parameters supplying traits or policies to allow extensive user customization?
A. Parameterization discourages users. The shared_ptr template is carefully crafted to meet common needs without extensive parameterization. Some day a highly configurable smart pointer may be invented that is also very easy to use and very hard to misuse. Until then, shared_ptr is the smart pointer of choice for a wide range of applications. (Those interested in policy based smart pointers should read Modern C++ Design by Andrei Alexandrescu.)

If parameterization discourages users, good, software engineers should be doing the programming not the users ;-). Seriously, I encountered few serious C++ people who would gasp at using std::string or std::vector<int>::const_iterator.

Q. There are several variations of shared pointers, with different tradeoffs; why does the smart pointer library supply only a single implementation? It would be useful to be able to experiment with each type so as to find the most suitable for the job at hand?
A. An important goal of shared_ptr is to provide a standard shared-ownership pointer. Having a single pointer type is important for stable library interfaces, since different shared pointers typically cannot interoperate, i.e. a reference counted pointer (used by library A) cannot share ownership with a linked pointer (used by library B.)

Wouldn't it be easier to just have one container class then as well? I mean all these container classes, if my code uses deque's but the library needs a vector, I have to convert my deque into a vector. Maybe smart ptr's shouldn't really be passed across library boundaries anyway. There's all kind of allocator issues and such. In the dynamic library world, you don't want library code freeing things allocated by the application and visa versa. So avoid policy based smart pointers for this reason isn't going to solve the problem anyway.

The only resistance I've seen when working with people and policy based smart pointers is from a debugging standpoint. Debuggers, and crashes with the type names get to be a bit daunting, but you get used to that if you're going to use the STL.

David Bradley