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

[<or...@vp...>]

Maxim Yemelyanov wrote:
> Do GCC really does like this? I mean, even if return value is class, not a
> referense?

Yes, that's what I said.

> 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).

WHAT?
No, what happens here is, that for getC(1) and getC(2) DIFFERENT objects 
will be returned. While would they be the same??? When you call getC(), 
then a LOCAL variable will be created. THAT local variable is returned 
without copy, as it would be destroyed anyway. So, instead of copying 
it, and destroying the local variable (as it gets out of scope at the 
end of getC), GCC will simply return c, without copy.
I don't see why this would cause a problem. Even in your example, it 
works perfectly.

I don't understand you clearly...

> I agree, this can happed, if getC is declared as returning reference:
> 
> C& getC(int something){ C c(something); return c; }

It is wrong. A function should NEVER return a reference to a LOCAL 
variable, as the local variable will be destroyed, and an invalid 
reference will be returned.

> , but that's what I always try to avoid

That is wise :)

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

I almost always use level 4 optimization, but at least level 3. It 
didn't cause any trouble for me so far. Even wxWindows is compiled with 
-O4 for me, and it works fine.
There is no problem using optimization - it won't do harm (in the 90% of 
the cases).

--
Greetings,
   Balázs