From -6534749234028410303 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,6788e79fcdcc2033 X-Google-Attributes: gidf78e5,public From: kanze@gabi-soft.fr (J. Kanze) Subject: Re: auto_ptr::reset and auto_ptr::operator= Date: 1995/09/22 Message-ID: #1/1 X-Deja-AN: 110577574 approved: matt@physics11.Berkeley.EDU (Matt Austern) references: <199509111753.AA15077@xs1.xs4all.nl> organization: GABI Software, Sarl. newsgroups: comp.std.c++ Greg Colvin (gregor@netcom.com) wrote: |> What to do when this==&rhs [in operator=] is still an open issue for the committee. Does it really need any special consideration. The semantics of operator= are defined as: reset( other.release() ) There is a sequence point before the call to reset, so other.release must finish executing before reset is called. If &other==this, there is still no problem: the pointer is first released, and so no longer belongs to other/this when reset is called. The net effect is a no-op. As this follows from the normal semantics, and is a possible and reasonable definition of the semantics for this case, why create a special case. While in this thread, I'd like to bring up another point which bothers me. I'll start by quoting some earlier postings which are relevant: Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote: |> Michael Cook writes: |> >I've been using auto_ptr with g++ (a 2.6 dialect). G++ generates bogus |> >warnings for certain expressions, but compiles the code correctly. |> > |> >The code it complains about is this: |> > |> > auto_ptr byValue(auto_ptr a); |> > a = byValue(b); |> > // warning: initialization of non-const `auto_ptr &' from |> > // rvalue `auto_ptr'. |> > |> >It doesn't quite seem to like the fact that the copy-assignment and copy-ctor |> >operators take non-const parameters. |> 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::operator= particularly problematic. 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. 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. 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. Does anyone have any other solutions, or suggestions as to what the standard *should* say? -- 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. ]