From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-02-05 16:19:41
David Bradley wrote:
> 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.
Sometimes you don't, and you use different smart pointers. Sometimes you do
want to hide implementation details from the client behind a single pointer
type, and you use shared_ptr. Or, if you insist on not using shared_ptr, you
use a raw pointer.
> 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?
shared_ptr<T> models T*.
T * create();
void destroy(T * p);
You don't know or care how the T is produced. Raw pointers have no secondary
parameter to encode (de)allocation details.
The above interface can be expressed as
No destroy() is necessary.
> 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
shared_ptr can safely be passed across library boundaries, even in the
dynamic library world.
How do you write a factory function that doesn't pass a smart pointer across
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk