Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!deb
From: deb@svax.cs.cornell.edu (David Baraff)
Newsgroups: comp.lang.c++
Subject: Re: Does C++ 2.0 Emit Following C Construct?
Message-ID: <32901@cornell.UUCP>
Date: 5 Oct 89 14:03:52 GMT
References: <32793@cornell.UUCP> <6590277@hplsla.HP.COM>
Sender: nobody@cornell.UUCP
Reply-To: deb@svax.cs.cornell.edu (David Baraff)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 27

In article <6590277@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
>My C++ 2.0 compiler [an s300 version] doesn't accept this construct --
>squawking about not a lvalue.
>
>NOTE:  I said the <C++ 2.0 compiler> NOT the backend C compiler won't accept 
>this -- my s300 C compiler will accept the construct.
>
>g++ 1.35.x will accept the construct.  
>
>To my way of thinking, not accepting a structure returned from a function
>as an lvalue makes perfect sense.  Or alternately, letting a returned 
>structure be an lvalue makes no more or less sense than letting a 
>returned "int" be an lvalue.  Compilers should be free to use a registered
>return value protocol for small structures.  Requiring a returned value
>to be an lvalue prevents this [or at least complicates it greatly.]
>
>Return a reference instead.  References are lvalues. See "thingcopy" verses
>"badcopy" below.

Perhaps I didn't make the problem clear enough. It was the 1.2
C++ compiler that emitted this code -- NOT me. All I was doing
was writing some standard matrix/vector stuff and I found
that the C code emitted contained these &f() constructs -- the original
C++ code had nothing resembling them!

So the 1.2 compiler emits bad C code. Original q: does the 2.0 compiler
ever do this?