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

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

shared_ptr<T> create();

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
> anyway.

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
library boundaries?