Re: Returning a Struct from a Function
* alex.j.k2@gmail.com:
On May 11, 2:02 pm, john <j...@gmail.com> wrote:
alex.j...@gmail.com dixit:
Hello, newbie here.
I'd like to know if there is a way to return a structure from a
function, without creating any other intermediate variables. Also,
this should be done such that the function can still be declared as
inline.
The usual way is to pass a reference to the struct (as a parameter) in
which you want to put the return value (the same for vector, list, ...)
OK, that certainly works.
But is this the only way to do it?
What if I have a lot of code which returns a struct (or vector,
etc..) by creating an intermediate variable in the function; and I do
not want to modify all the occurrences of the function in the code,
only the function itself.
Can I eliminate the creation of the extra variable, while returning
the struct (but not as a parameter) ?
In general one should not optimize prematurely. However, designing a
program so that it needlessly copies megabytes of data in function
calls is ungood. The advice about optimization is really about
micro-optimization, not about not applying common sense.
For a large vector or something like that, the simplest technique is
to provide 2 variants of your function:
void getDataset( std::vector<Whatever>& result )
{
std::vector<Whatever> tempResult;
// Fill in tempResult here, then:
tempResult.swap( result );
}
inline std::vector<Whatever> dataset()
{
std::vector<Whatever> result;
getDataset( result );
return result;
}
Now users can just use the simple function call notation for
dataset(), until they discover that hey, this is a performance
bottleneck, at which time they measure, find that it's your dataset()
that's doing a lot of copying, and then switch to using getDataset().
But that may in reality never occur, because a modern compiler is
likely to do Return Value Optimization, where a call of dataset()
produces machine code almost like it was getDataset that was called
directly -- the "almost" is because RVO is more efficient than that.
If one is pessimistic enough to believe that (1) the user's compiler
won't do RVO, and (2) the conditions for the performance problem
(enough data, called repeatedly) will be present, and (3) clean
notation like the dataset() function is required, then the only
recourse is to implement something like RVO manually. Usually that's
called "move semantics". For example, Andrei Alexandrescu has
implemented a std::vector replacement with move semantics (part of his
YASLI which it seems will never be completed), plus a general
framework for move semantics called Mojo. As another example, a
number of people were involved in implementing two smart pointers
called move_ptr for a Boost proposal; it was not accepted but still
the code could help. As a third example, Howard Hinnant has
implemented an emulation of C++0x unique_ptr (however, older compilers
such as MSVC 7.1 don't like that code).
But if you don't want that new-fangled stuff, then there's nothing
very wrong in this context with just using std::auto_ptr, which is a
smart pointer with ownership transfer, almost like move semantics.
That usage can, if needed, be wrapped in a little class. The downside
is that using a smart pointer as result type is that (A) the notation
is a little bit less clean (after all, it's a pointer), and (B) it
involves an additional dynamic allocation and indirection.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?