🚀 go-pugleaf

In article <4kjcvb$ghf@ugress.uib.no> boukanov@sentef1.fi.uib.no (Igor
Boukanov) writes:

|> Greg Colvin (gregor@netcom.com) wrote:
|> > This was a hard call, and I'm open to suggestions.  Adding a mutable
|> > member to a class is never pretty, but making the member visible in any
|> > way is ugly:  I don't like for a const argument to change its value,
|> > and I think of the value of an object as being whatever its public
|> > interface reveals. 

|> But why in this case instead of adding mutable member just change
|> auto_ptr<T>(const auto_ptr<T>&) to auto_ptr<T>(auto_ptr<T>&)
|> and 
|> auto_ptr<T>& operator=(const auto_ptr<T>&) to
|> auto_ptr<T>& operator=(auto_ptr<T>&)

|> This will explicitly reflect the semantic of auto_ptr and if somebody really 
|> want to change the state of const object, they can explicitly wright
|> about this:
|> auto_ptr<someType> autoPtr(const_cast<auto_ptr<someType>&>(autoPtrConst)); 

We've been through all this before.  That was the original version.
Regretfully, makes it impossible to return an auto_ptr from a function.
And one of the more frequent uses of auto_ptr involves returning them
from functions.
-- 
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.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]