Re: [Dev-C++] #DEFINE versus cont variables in array inicializations
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
|
From: Per W. <pw...@ia...> - 2003-05-30 15:20:14
|
What smart compilers do, is to let the caller allocate the memory for the
temporary object, and then have the function perform all object
manipulation with the temporary object. On return, there is no need for
any object copying, since the resulting object is in the callers stack
frame and not in the called functions.
If the caller wants to make two calls, the compiler will - depending on
object usage - allocate one or two temporary objects that the called
function will use.
/Per W
On Fri, 30 May 2003, OROSZI Bal=E1zs wrote:
> Maxim Yemelyanov wrote:
> > Do GCC really does like this? I mean, even if return value is class, no=
t 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 (becaus=
e 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 "optimiz=
e 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=E1zs
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
|