Re: [boost] Re: smarter auto_ptr

From: Bronek Kozicki (brok_at_[hidden])
Date: 2004-01-18 16:13:34

Howard Hinnant <hinnant_at_[hidden]> wrote:
>   And I like the idea of a policy deleter class, though I do not want
> to pay any overhead for the policy when it is stateless (i.e.
> sizeof(smart_pointer) == sizeof(void*) for common cases).

Sorry, I'm affraid I cannot delived support for deleters in such small
class. The main reason behind deleter is not to allow use of policy
class, but to allow definition of deletion function at the point where
smart pointer is being initialized from raw pointer, and only there (as
opposed to current std::auto_ptr). Under such assumption this deletion
function must be stored somewhere with managed pointer - even if its
trivial delete or no-op.

>     One should never move from lvalues with copy syntax.
[...]
> template <class T>
> T foo(T t)
> {
>      ...
>      T temp = t;  // assumes copy (t isn't supposed to change here)
>      ...
>      return t;
> }

I see. Disallowing this would actually mean to make inacessible copy
constructor and assignment operator. I know your proposal N1377 and I
really like it, however under current C++ I see no possibility to
deliver such smart pointer with strong ownership semantics (or maybe
some guru will elighten me).

> In summary, I think an "improved auto_ptr" must "pass" the above test
> by failing to compile.  I also believe the name "auto_ptr" should not
> be used for such a smart pointer because of backwards compatibility
> issues.

I really wish that your proposal will be accepted. In this case we will
need to redefine whole standard library to make good use of it (maybe
NTLLib can be used as inspiration ?). This will be also good time to
deliver smart pointer with *real* move semantics. Currently language
just does not support move semantics, and even if we use smart template
classes to provide similar semantics, the required syntax will be
un-natural, thus many developers will not likely use it. And if we allow
natural copy syntax (as it is available now), we again fall into trap
you just described ...

B.