Re: [boost] Re: Re: Smart pointers: One more implementation + question

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
>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
    <http://cseng.aw.com/book/0,,0201704315,00.html> 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