🚀 go-pugleaf

In section 6.6.3 on page 90 the ARM states:

"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?

Consider this example:

template<class T>
class A
{
  public:
    A(T *p) : ptr(p) {}
    ~A() {if (ptr) *ptr = 0;}
  private:
    T *ptr;
};


int
func1()
{
    int x = 10;
    A<int> a(&x);
    return x;
}


Under cfront 3.0.1, func1() returns 0, not 10, even though the value of
x in the return statement is clearly 10.  The value of x is changed to
0 due to the destructor of the A object going out of scope at the end
of the function.

What's more interesting is that if a func2() is created that returns
by value an object of a class type with a constructor and destructor,
the desired value is returned because of the generation of a
temporary:

class B
{
  public:
    B(int x) : val(x) {}
    ~B() {}
    void operator=(int x) {val = x;}
    operator int() {return val;}
  private:
    int val;
};

B
func2()
{
    B b(10);
    A<B> a(&b);	// same A as above
    return b;
}


In this case, func2() returns a B whose val member has a value of 10,
due to the generation of a temporary, even though the same A
destructor sets the value to 0.

Shouldn't both of these cases perform the same way?  Is this a cfront
bug?  Shouldn't the value of the return expression be returned to the
caller regardless of side effects of destructors for auto objects?
Does the language enforce any of this?  The pre-Boston mailing doesn't
seem to discuss this any differently than the ARM does.

thanks,
-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.