In article <3jfio5$mb1@panix3.panix.com>,
Timothy Murphy <tmurphy@panix.com> wrote:
:
:Non-constant references to temporaries.
:
:Timothy S. Murphy   5 March 1995.

The one that I do most often is try to write one thing (or one stream of
things to a file.)  For example, I might wish to write a port number to
a file:

 ofstream ("port.fil") << portno;

The compiler won't let me do this because the temporary object created can't
call the non-const operator<< member function.  It's not like it's a major
deal, but it is a hassle to have to create the variable name for it and
do the write in separate statements.  Anyway, another example of where
being able to modify a temporary would be useful.

--
Stephen Gevers
sg3235@shelob.sbc.com

Non-constant references to temporaries.

Timothy S. Murphy   5 March 1995.


  A few observations and proposals regarding the C++ language standard.
The last draft specification (DS) I looked at was dated 20 September 1994;
I also refer to the ARM.

   Please rip this apart, both with your editor and your words; I am
very interested in feedback, particularly from members of the standards
committee.


   [DS 8.5.3] prohibits the binding of non-constant references to
temporary objects.  I find this prohibition unnatural and obstructive
and I propose its removal.  There is absolutely no reason to prohibit
mutation of a temporary object and, in fact, such mutations arise naturally.

   The utility of non-constant temporaries is easily seen when
implementing large arithmetic objects such as matrices.  Consider
operator+ on matrices.  What should be the type of its return value?
A matrix is the obvious, but suboptimal, answer.  A better return
type would be a "dirtyMatrix", which is basically a matrix except that
a matrix may be constructed from a (nonconstant reference to a)
dirtyMatrix by stealing its memory; note that this is safe and avoids
needless allocation and copying of large numeric arrays.  Note
also that it requires the binding of a nonconstant reference to a temporary
object; artificially changing the argument type of the aforementioned
constructor to "const dirtyMatrix&" forces all the data members of matrix
to be "mutable".  This latter approach is unnatural and dangerous and
also relies on a language feature not yet implemented in most compilers.

   Other examples abound (strings are similar to matrices).

   I fail to see why temporaries must be const.

-- Timothy S. Murphy: A serious user and admirer of C++.
   tmurphy@panix.com

In article <3jfio5$mb1@panix3.panix.com>,
Timothy Murphy <tmurphy@panix.com> wrote:
>
>Non-constant references to temporaries.
>
>   I fail to see why temporaries must be const.

 They're not. Member functions can modify them.
They only look const to normal reference binding.
So you can write:

 class X { X* operator&() { return this; } };
 X f();
 void g(X&);
 g(*&f());

You can also use the unsafe hackery

 template<class T> T& cheat(const T& t) {
  return const_cast<T&>(t);
 }

to obtain a non-const reference to an rvalue. AFAIK using
it is always legal when bound to a temporary, and safe provided
binding it is used to bind a _function parameter_.  Of course:

 int &ir = cheat(1); //  .. woops
 cout << ir;

is not well defined. I personally agree with you that the
non-orthogonality introduced into the language by this rule
is more of a hassle than noticing warnings which compilers
could produce. (They already produce errors here so changing
them to warnings is trivial).

A compromise is to permitt _addressing_ rvalues, so that

 *&T()

was a non-const reference to the temporary T object: this
code is no accident, and one can "grep" for "*&".


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189