Re: [C++] Returning objects from a function and performance
From: Alwyn (alwyn_at_blueyonder.co.uk)
Date: 02/21/05
- Next message: davidrubin_at_warpmail.net: "Re: Containing containers - handling interface ?"
- Previous message: John Salerno: "Re: C++ or C#?"
- In reply to: Spacen Jasset: "[C++] Returning objects from a function and performance"
- Next in thread: Vince Morgan: "Re: [C++] Returning objects from a function and performance"
- Reply: Vince Morgan: "Re: [C++] Returning objects from a function and performance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 21 Feb 2005 19:33:22 +0000
On Mon, 21 Feb 2005 15:18:03 +0100, Spacen Jasset wrote:
> If I have a function that resturns a class object. i.e.
>
> ExtString mid( int start, int len )
> {
> ExtString result;
> ...
> return result;
> }
>
> Then the compiler must invoke the copy constructor of ExtString to make
> a copy and return it. Unless ofcourse it can be optimised.
There is something called Return Value Optimisation, which, if
implemented, would do away with the need to make a copy.
> But surpose the function is like this:
>
> ExtString mid( int start, int len )
> {
> ExtString result1;
> ExtString result2;
>
> if ( /* something )
> return result1;
> else
> return result2;
> }
>
> The compiler would have a harder time optimising that I suspect.
I'm not sure why.
> I ask this question becuase I've been told that this is all very
> inefficient and the 'mid' and other functions have been re-written in
> our library to take a refrence like this:
>
> void mid( ExtString &sub, int start, int len ) { ...
> }
Yes, you can do that, but I would only recommend such a style if it has
been shown (e.g. by means of a profiler) that it eliminates a real
bottleneck in performance. Producing results by side-effect is to be
avoided where possible.
> Is returning a potentially large object from a function as bad as it
> seems? I notice the std::string.substring() function also returns a
> string object. This looks like a popular thing to do in C++.
'std::string' is hardly what I would call a large object. I would say the
overhead here is probably the memory allocation.
> It's still traditional amoung C programmers to never return structures
> by value, despite being able to do so officialy since C89.
I didn't know that.
> Presumably
> there is a considerable performance problem for large objects in C++,
> but perhaps notso in C since there are no copy constructors, and the
> compiler can avoid any object copy on return.
The C++ standard insists on memberwise copy, though this too can be
optimised 'behind the scenes' to a straight memory copy in the case of
POD. And, as I said before, the overhead of creating a temporary object
can be avoided if the compiler is capable of return value optimisation. On
the whole, I believe in leaving micro-optimisation to the compiler until
it is shown that the impact on performance is such that it really does
need to be done by hand.
Alwyn
- Next message: davidrubin_at_warpmail.net: "Re: Containing containers - handling interface ?"
- Previous message: John Salerno: "Re: C++ or C#?"
- In reply to: Spacen Jasset: "[C++] Returning objects from a function and performance"
- Next in thread: Vince Morgan: "Re: [C++] Returning objects from a function and performance"
- Reply: Vince Morgan: "Re: [C++] Returning objects from a function and performance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|