🚀 go-pugleaf

In article <479thu$9k4@bcarh8ab.bnr.ca> "ian (i.) willmott"
<willmott@bnr.ca> writes:

|> Matt Austern:
|> >I don't know of any simply way to modify the definition of auto_ptr in
|> >the standard to avoid this difficulty: it seems to follow from the
|> >semantics of strict ownership.

|> It seems to me that this example tends to indicate that the prohibition of
|> non-const references to rvalues is a bad idea, at least for function
|> parameters. Section [basic.lval] suggests that you can in fact call
|> a non-const member function on a temporary object, so it's also inconsistent
.
|> Why distinguish between member and non-member functions in this respect?

|> Surely there is a whole class of situations like this where the destructor
|> for a temporary has side effects which you may want to avoid or change by
|> modifying the object before it goes out of scope. I'm not sure what the ARM
|> means by "a major source of surprises"; if you pass a temporary as a referen
ce
|> parameter, it's obviously going to evaporate after the function returns,
|> no matter what the function does or doesn't do to it.

The surprise occurs when you `accidentally' pass a temporary, such as
the result of an implicit conversion.  Consider the following:

	void
	incr( int& i )
	{
	    i ++ ;
	}

	unsigned        j( 0 ) ;
	incr( j ) ;                   //  j unchanged!!!

I suppose the best rule would be to simply ban implicit conversions,
and make the programmer say what he means.  But I rather suspect that
the amount of code that this would break will prohibit any such
change.
--

James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-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. ]