Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: Does C++ 2.0 Emit Following C Construct?
Message-ID: <6590277@hplsla.HP.COM>
Date: 4 Oct 89 18:17:03 GMT
References: <32793@cornell.UUCP>
Organization: HP Lake Stevens, WA
Lines: 45

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.

See example program below:


#include <stdio.h>

class thing
{
  const char* const name;
public:
  thing(char* nm):name(nm){}
  thing(const thing& that):name(that.name){}
  void print(){printf("thing is named: %s\n",name);}
  friend thing& thingcopy(const thing& that) {return *(new thing(that));}
  friend thing badcopy(const thing& that) {return that;}
};

main()
{
  thing* p;
  thing amagig("IamAgig");

  p = &(thingcopy(amagig));
  p->print();

  // p = &(badcopy(amagig));  C++ 2.0 complains: not an lvalue
  p->print();
}