From: David Bradley (dbradley_at_[hidden])
Date: 2003-02-05 16:02:07
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
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
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:
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
<http://cseng.aw.com/book/0,,0201704315,00.html> by Andrei
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk