🚀 go-pugleaf

kanze@gabi-soft.fr (J. Kanze) writes:

>Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
>|> Michael Cook <mcook@cognex.com> writes:
>
>|> >    auto_ptr<V> byValue(auto_ptr<V> a);
>|> >    a = byValue(b);
>|> >    //   warning: initialization of non-const `auto_ptr<V> &' from
>|> >    //   rvalue `auto_ptr<V>'.
>
>|> That warning is not bogus; on the contrary, the code is ill-formed,
>|> and the draft standard *requires* a diagnostic.
>|> (5.2.2/3 says that argument passing is treated as initialization,
>|> and 8.5.3/8 says you can't initialize a non-const reference with
>|> an rvalue.)
>
>To which Michael Cook (mcook@cognex.com) responded:
>
>|> Hmm.  Interesting.  That means the auto_ptr class can't be used that way.
>|> That surprises me.
>
>It not only surprises me, it bothers me profoundly. I find the
>parameter declaration of auto_ptr<T>::operator= particularly
>problematic. 

Yes, I agree: I too find the auto_ptr assignment operator very disturbing,
though possibly for slightly different reasons.  I don't like the semantics
of the assignment operator: it does not just copy the auto_ptr, it
also invalidates the source of the copy.  I think that using `operator ='
for this operation is an abuse of operator overloading.

>On one hand, the right hand side of assignment definitly
>*is* modified; declaring it const (and casting away const in operator=
>is order to implement the current semantics) would be outright lying to
>the user.  It is also lying to the compiler; presumably at some future
>date, a compiler will take advantage of this const declaration in order
>to implement some fancy optimization, which will break in the case of
>casting away const.

Right.  This would awful; certainly much worse than the current situation.

>On the other hand, using an auto_ptr as the return value of a function
>would seem to be one of its principal uses.  Not allowing this would
>almost render auto_ptr useless.

I don't think so.  Instead of returning an auto_ptr<T>, you can
just return the T* obtained from a call to auto_ptr<T>::release().
The caller can use this T* to initialize another auto_ptr<T>.

>My current solution (in my personal implementation) is to declare the
>parameter of operator= const, with *big* warnings in comments at the
>point of declaration that this is a lie, and to declare the pointer
>member mutable, so as to tell the compiler that the const may be a lie.
>Hardly what I would call ideal, but the best I've been able to come up
>with til yet.

This is an awful abuse of both `mutable' and `const', and a horrible
hack, IMHO.  I wouldn't recommend it.

>Does anyone have any other solutions, or suggestions as to what the
>standard *should* say?

I think the assignment operator and copy-constructor of auto_ptr
ought to be declared private.  If you want to copy an auto_ptr,
then instead of writing

	auto_ptr<T> y = x;	// copy constructor
	y = x;			// assignment operator


you should have to write

	auto_ptr<T> y = x.release();
	y = x.release();

This makes it clear that x is being modified.

-- 
Fergus Henderson             |  "Australia is the richest country in the world,
fjh@cs.mu.oz.au              |   according to a new system of measuring wealth
http://www.cs.mu.oz.au/~fjh  |   announced by the World Bank yesterday."
PGP: finger fjh@128.250.37.3 |  - Melbourne newspaper "The Age", 18 Sept 1995.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]