I see, that's quite clever. Thank-you for the explanation Hodgman. Is this your preferred method of returning dynamic data from functions?

Not that it really matters, but I can't for the life of me figure out why this comment would warrant a thumb down...

I almost always use (1) or (4), because its more purely functional form results in the cleaner flow of data through your code. Consider which one of these you'd rather write as a user:

auto result = Foo(Bar1(x), Bar2(y), Bar3(z));

or:

Bar1ResultT bar1;
Bar1(x, bar1);

Bar2ResultT bar2;
Bar2(y, bar2);

Bar3ResultT bar3;
Bar3(z, bar3);

FooResultT result;
Foo(bar1, bar2, bar3, result);

That being said, (2) is useful in cases when you want to use the return value to indicate success/failure (if the results are sometimes unavailable or invalid), or there's some other associated state that comes along with them. But to me it's a more difficult interface to use, so there has to be a specific reason to choose it -- it's never the default.

Consider which one of these you'd rather write as a user:

Well, to be perfectly honest neigther of those are really optimal, I would still rather write a mixup of both:

const auto bar1 = Bar1(x);
const auto bar2 = Bar2(y);
const auto bar3 = Bar3(z);

const auto result = Foo(bar1, bar2, bar3);

Mostly for easier debugging by being able to directly step into Foo with just one keypress. But I agree with your point, I personally try to the reference-out approach as much as possible, since it adds lots of complexety without many gains in most places.

Slightly contrarian view: I prefer #2 to #1, and definitely over #4.

#2 is very much a common C/C++ pattern. Pass in the output object (or struct in C) and let the function fill it out. It looks a little weird at first but experienced programmers will understand exactly what's going on. Probably even more so than #1, and definitely more so than #4.

#2 removes any confusion about where the allocation takes place, who is responsible for it, etc. The caller has control over whether the object gets reused, and that decision can easily be refactored at some later point without changing the function at all.

Now, it's not all pretty and functional looking. But, this is C++ we're talking about. If you wanted pretty, you came to the wrong place.

Sorry to disagree. I mostly just wanted to point out that #2 is common C/C++ and you'll run into it all over the place.

Geoff

#2 removes any confusion about where the allocation takes place, who is responsible for it, etc. The caller has control over whether the object gets reused, and that decision can easily be refactored at some later point without changing the function at all.

Actually, I'd heavily disagree with that part. #2 Actually adds a lot of confusion about what happens to the object you pass in. The callee might do all sorts of it: Clear it, not clear it, append items to it, remove items from it, reserve() memory of it, force_to_shrink it, std::swap it with another vector, etc... so all sorts of things, not only on such a syntactical, but also on more functional level (is the vector supposed to be cleared by the callee? is it already cleared by the caller? Do you call reserve(), because you are the only one filling it at one point, or are multiple consecutive calls happening so this would be harmful? ...) which makes the actual purpose of the function pretty much ambigous, no matter your level of experience in C++.

In #1 on the other hand, there's only one logical, if not possible purpose: The function creates a new collection of objects and returns it, period. So unless you are overly familiar with #2, I'd say #1 should be more understandably. #2's main purpose is to provide potential speedups, otherwise I personally tend to only use it if I want to actually append to an array via multiple unrelated calls.

Sorry to disagree. I mostly just wanted to point out that #2 is common C/C++ and you'll run into it all over the place.

No need to apologice for disagreeing with anything!

I'd argue that generally, there's lot of legacy code like #2 floating around, with people claimings its actually easier to understand, without being actually wrong about it - you're just common to it, like you said, its common C++-code, but from a more objective standpoint, I'd often rather prefer newer approaches.

But, this is C++ we're talking about. If you wanted pretty, you came to the wrong place.

Still, C++XX did a lot to simplify the language and make it actually prettier - while its certainly not C++' selling feature, there's nothing wrong with it eigther - I mean, the point of C++ is not to be as ugly as possible, is it? :)

I mean, the point of C++ is not to be as ugly as possible, is it? :)

You know, every time I do template meta-programming I start to ask myself that very question...

Actually, I'd heavily disagree with that part. #2 Actually adds a lot of confusion about what happens to the object you pass in. The callee might do all sorts of it: Clear it, not clear it, append items to it, remove items from it, reserve() memory of it, force_to_shrink it, std::swap it with another vector, etc... so all sorts of things, not only on such a syntactical, but also on more functional level (is the vector supposed to be cleared by the callee? is it already cleared by the caller? Do you call reserve(), because you are the only one filling it at one point, or are multiple consecutive calls happening so this would be harmful? ...) which makes the actual purpose of the function pretty much ambigous, no matter your level of experience in C++.

Agreed. I also tend to find #2 to be the hardest to maintain of the options. Every pointer- or reference-taking method is a rabbit-hole that must be followed to fully understand how your data is being manipulated, and such methods are often improperly reused or extended to meet the (potentially competing) needs of multiple users.