🚀 go-pugleaf

In article <gregorDLrrun.K2x@netcom.com> gregor@netcom.com (Greg
Colvin) writes:

|> Our working paper's auto_ptr (20.4.5) specifies a non-const copy constructor

|> and assignment operator.  This specification makes functions that return
|> auto_ptr less useful than I intended, due to a language restriction on
|> modifying temporaries.  Since changing the language specification seems not
|> to be an option, a change to auto_ptr is in order.  

I'll admit that I was toying with the idea of a change in the language
specification.  The problem does not just affect auto_ptr.  I have a
number of functions for which the user typically will want to pass a
temporary, but which will modify this temporary.

While toying with this last night, it occured to me that there is a
very simple solution: add an `asLValue' function:

	template< class T >
	class auto_ptr
	{
	public :
	    auto_ptr< T >&      asLValue()
	    {
	        return *this ;
	    }
	    //  ...
	} ;

This allows leaving the parameters to operator= and the copy
constructor non-const, but will permit assigning/copying the return
value of a function, by explicitly invoking `asLValue':

	auto_ptr< T >       f() ;

	auto_ptr< T >       p1( f().asLValue() ) ;
	p1 = f().asLValue() ;

This gives auto_ptr the semantics I and Bill Gibbons felt important:
that the pointer is *never* released from an auto_ptr, but maintains
the definition of const desired by Fergus Henderson and others; a
const object is not modified, and a function which declares a
parameter as a const reference does not modify that parameter.

Note that in fact, the `asLValue' function is not const, and cannot be
called on a const object.  It can be called on a temporary, though,
and since it returns a non-const l-value, its results can be bound to
a non-const reference (i.e.: the parameter to the copy constructor or
the assignment operator).

As this idea has just occured to me, I've not had the time to work out
all of the implications.  (One thing is sure: it needs a better
name:-).)  Still, I think it might be worth looking into.

--
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, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]