🚀 go-pugleaf

In article <BxKs87.417@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
>"A return statement with an expression can be used only in functions
>returning a value; the value of the expression is returned to the
>caller of the function."
>
>Given the statement
>
>	return foo;
>
>where foo is an object with some value, does the statement from the
>ARM mean that the compiler *must* return the value that foo has in the
>return statement, rather than the value foo might have at some point
>after the destructors for local automatic objects have been executed?

[ example deleted: it's designed so that the destructor of an auto
  variable will alter foo's value. ]

Your example is the kind of thing that I think language standards should
leave explicitly undefined; otherwise compiler vendors will have to
generate worse code just in case someone like you gets tricky. :-)

>Shouldn't both of these cases perform the same way?

I don't think so (if that means a change is required in the draft
standard, so be it).

>Is this a cfront bug?

Again, I don't think so.  I'm not willing to pay the cost of the
extra copy operation that might be required were the committee to
force your example to work.  It's simply not worth slowing down reasonable
C++ programs to have defined behavior on your unreasonable example (it is
cute, though).  There is already precedent: the ANSI
C standard leaves the order of side effects explicitly undefined in
examples like

	void func(int,int);
	int i = 3;
	func(i++,i++);

The ARM statement needs amendment in any case, as it says elsewhere that
the copy constructor is called to return objects, and there is no
guarantee that the user will write a proper copy constructor.





--
Joe Buck	jbuck@ohm.berkeley.edu