🚀 go-pugleaf

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
|> 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.

After reading your posting, I agree.  This is really the cause of the
problem.  Operator= (and copy construction) has generally accepted
semantics.  The operator= of auto_ptr does not follow these semantics.

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

This is awful.  Returning an auto_ptr guarantees that the memory is on
the heap.  A T* contains no such guarantee, and a T* returned from a
function should not be used to initialize an auto_ptr. <grin>

Seriously, there is a part of truth in what I say above.  I detest the
idiom in which functions return pointers to the heap, and expect the
caller to delete them.  I was hoping that auto_ptr would solve this
problem in an elegant way.

Oh well, back to my old RefCntPtr<T> class.

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

I only recommend it as the lessor of two evils, but you've almost
convinced me to eshew auto_ptr completely.  Which is a shame, because I
very much like what the class is trying to do.

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

I agree with this for general use.  The problem is function return
values.  OK, the object in question is being modified, although you
promissed (with const) not to.  But since the object in question ceases
to exist immediatly after the modification, who cares? :-)

Ideally, perhaps, I would want to have assignment and copy construction
defined only when the source is a temporary.  In practice, in my own
code, I find that in fact, all (or almost all) of the assignments and
copies are in fact from temporaries.  (Off hand, I cannot remember any
that wasn't either a function return value, or a parameter to a
function.)  So I find that my solution, while ugly WRT C++ programming,
does correspond to what I expect an auto_ptr to do.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung
---
[ 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. ]