Re[2]: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Maxim Y. <ma...@en...>]

Hello, OROSZI!

Friday, May 30, 2003 0:10:34 You wrote to dev...@li...:
OB> Per Westermark wrote:
>> I guess you don't think of gcc as a decent compiler then.

OB> An interesting thing I found, when examining g++ deeply:
OB> GCC is so smart, it even optimizes everything possible.
OB> Suppose you have a function, that returns a class. The normal behaviour 
OB> would be: call copy constructor, return copied object.
OB> BUT if the variable was a local variable (created in the function) and 
OB> you return that, then the "theoretical" behaviour would still be: copy 
OB> object, return copied object, delete local variable, BUT gcc makes it 
OB> very different: it simply return the local object without any copy, etc. 
OB> It is not harmful, as the object would have been deleted anyway, so it 
OB> is truly easier to simply return the local variable one-in-one. It is 
OB> faster for sure.
Do GCC really does like this? I mean, even if return value is class, not a
referense? That's terrible then! Because you can run into trouble when the
returned value should be used in another function call: 

class C { ... };

C getC(int something){ C c(something); return c; }

void f(C& c1, C& c2);

f(getC(1), getC(2)); <-- one of C objects will override another (because it
can (or "will") be created at the same address).

I agree, this can happed, if getC is declared as returning reference:

C& getC(int something){ C c(something); return c; }

, but that's what I always try to avoid (yes, I have functions like 'f', they
work with std::string objects);

OB> It truly does this, as I stated - I have checked the pointer for the
OB> object, and it is the same in the function, and the after return.

OB> Interesting...
I usually turn off any optimization, 'cos I heard that GCC can "optimize too
much" :-)

-- 
Regards!
Maxim