tags:

views:

6555

answers:

12

Is there a preferred way to return multiple values from a C++ function? For example, imagine a function that divides two integers and returns both the quotient and the remainder. One way I commonly see is to use reference parameters:

void divide(int dividend, int divisor, int& quotient, int& remainder);

A variation is to return one value and pass the other through a reference parameter:

int divide(int dividend, int divisor, int& remainder);

Another way would be to declare a struct to contain all of the results and return that:

struct divide_result {
    int quotient;
    int remainder;
};

divide_result divide(int dividend, int divisor);

Is one of these ways generally preferred, or are there other suggestions?

Edit: In the real-world code, there may be more than two results. They may also be of different types.

A: 

Alternatives include arrays, generators, and inversion of control, but none is appropriate here.

Some (e.g. Microsoft in historical Win32) tend to use reference parameters for simplicity, because it's clear who allocates and how it will look on the stack, reduces the proliferation of structures, and allows a separate return value for success.

"Pure" programmers prefer the struct, assuming it is the function value (as is the case here), rather than something that's touched incidentally by the function. If you had a more complicated procedure, or something with state, you'd probably use references (assuming you have a reason for not using a class).

Mark
+4  A: 

It's entirely dependent upon the actual function and the meaning of the multiple values, and their sizes:

  • If they're related as in your fraction example, then I'd go with a struct or class instance.
  • If they're not really related and can't be grouped into a class/struct then perhaps you should refactor your method into two.
  • Depending upon the in-memory size of the values you're returning, you may want to return a pointer to a class instance or struct, or use reference parameters.
Stewart Johnson
+35  A: 

For returning two values I use a std::pair (usually typedef'd). You should look at boost::tuple for more than two return results.

Rob
My thoughts exactly! +1 :)
Drew Hall
+1 for tuple. Keep in mind the performance ramifications of large objects returning in a structure vs. passing by reference.
Marcin
If you're going to use tuples, why not use them for pairs as well. Why have a special case?
Ferruccio
Can boost::tuple handle different types in the same tuple? Maybe you can use boost::any with it.
Fred Larson
Fred, yes boost::tuple can do that :)
Johannes Schaub - litb
It's been a while, but I guess I'll accept this answer as the crowd favorite.
Fred Larson
+7  A: 
std::pair<int, int> divide(int dividend, int divisor)
{
   // :
   return std::make_pair(quotient, remainder);
}

std::pair<int, int> answer = divide(5,2);
 // answer.first == quotient
 // answer.second == remainder

std::pair is essentially your struct solution, but already defined for you, and ready to adapt to any two data types.

James Curran
That'll work for my simple example. In general, however, there may be more than two values returned.
Fred Larson
Also not self-documenting. Can you remember which x86 register is the remainder for DIV?
Mark
@Mark - I agree that positional solutions can be less maintainable. You can run into the "permute and baffle" problem.
Fred Larson
+1  A: 

I tend to use out-vals in functions like this, because I stick to the paradigm of a function returning success/error codes and I like to keep things uniform.

John Dibling
A: 

I'd say there is no preferred method, it all depends on what you're going to do with the response. If the results are going to be used together in further processing then structures make sense, if not I'd tend to pass then as individual references unless the function was going to be used in a composite statement:

x = divide( x, y, z ) + divide( a, b, c );

I often choose to pass 'out structures' by reference in the parameter list rather than having the pass by copy overhead of returning a new structure (but this is sweating the small stuff).

void divide(int dividend, int divisor, Answer &ans)

Are out parameters confusing? A parameter sent as reference suggests the value is going to change (as opposed to a const reference). Sensible naming also removes confusion.

Patrick
I think it's a bit confusing. Someone reading code that calls it sees "divide(a,b,c);". There's no indication that c is an outval until they look up the signature. But that's a general fear of non-const reference params, rather than particular to this question.
Steve Jessop
A: 

Boost tuple would be my preferred choice for a generalized system of returning more than one value from a function.

Possible example:

include "boost/tuple/tuple.hpp"

tuple< int, int > divide( int dividend, int divisor ) {

return make_tuple( dividend / divisor, dividend % divisor )

}

AndyUK
+1  A: 

If your function returns a value via reference, the compiler cannot store it in a register when calling other functions because, theoretically, the first function can save the address of the variable passed to it in a globally accessible variable, and any subsecuently called functions may change it, so the compiler will have (1) save the value from registers back to memory before calling other functions and (2) re-read it when it is needed from the memory again after any of such calls.

If you return by reference, optimization of your program will suffer

dmityugov
+6  A: 

Personally, I generally dislike return parameters for a number of reasons:

  • it is not always obvious in the invocation which parameters are ins and which are outs
  • you generally have to create a local variable to catch the result, while return values can be used inline (which may or may not be a good idea, but at least you have the option)
  • it seems cleaner to me to have an "in door" and an "out door" to a function -- all the inputs go in here, all the outputs come out there
  • I like to keep my argument lists as short as possible

I also have some reservations about the pair/tuple technique. Mainly, there is often no natural order to the return values. How is the reader of the code to know whether result.first is the quotient or the remainder? And the implementer could change the order, which would break existing code. This is especially insidious if the values are the same type so that no compiler error or warning would be generated. Actually, these arguments apply to return parameters as well.

Here's another code example, this one a bit less trivial:

pair<double,double> calculateResultingVelocity(double windSpeed, double windAzimuth,
                                               double planeAirspeed, double planeCourse);

pair<double,double> result = calculateResultingVelocity(25, 320, 280, 90);
cout << result.first << endl;
cout << result.second << endl;

Does this print groundspeed and course, or course and groundspeed? It's not obvious.

Compare to this:

struct Velocity {
    double speed;
    double azimuth;
};
Velocity calculateResultingVelocity(double windSpeed, double windAzimuth,
                                    double planeAirspeed, double planeCourse);

Velocity result = calculateResultingVelocity(25, 320, 280, 90);
cout << result.speed << endl;
cout << result.azimuth << endl;

I think this is clearer.

So I think my first choice in general is the struct technique. The pair/tuple idea is likely a great solution in certain cases. I'd like to avoid the return parameters when possible.

Fred Larson
+1  A: 

There is precedent for returning structures in the C (and hence C++) standard with the div, ldiv (and, in C99, lldiv) functions from <stdlib.h> (or <cstdlib>).

The 'mix of return value and return parameters' is usually the least clean.

Having a function return a status and return data via return parameters is sensible in C; it is less obviously sensible in C++ where you could use exceptions to relay failure information instead.

If there are more than two return values, then a structure-like mechanism is probably best.

Jonathan Leffler
+1  A: 

Use a struct or a class for the return value. Using std::pair may work for now, but 1) it's inflexible if you decide later you want more info returned; and 2) it's not very clear from the function's declaration in the header what is being returned and in what order. Returning a structure with self-documenting member variable names will likely be less bug-prone for anyone using your function. Putting my coworker hat on for a moment, your divide_result structure is easy for me, a potential user of your function, to immediately understand after 2 seconds. Messing around with ouput parameters or mysterious pairs and tuples would take more time to read through and may be used incorrectly. And most likely even after using the function a few times I still won't remember the correct order of the arguments.

Michel
+4  A: 

The OO solution for this is to create a ratio class. It wouldn't take any extra code (would save some), would be significantly cleaner/clearer, and would give you some extra refactorings letting you clean up code outside this class as well.

Actually I think someone recommended returning a structure, which is close enough but hides the intent that this needs to be a fully thought-out class with constructor and a few methods, in fact, the "method" that you originally mentioned (as returning the pair) should most likely be a member of this class returning an instance of itself.

I know your example was just an "Example", but the fact is that unless your function is doing way more than any function should be doing, if you want it to return multiple values you are almost certainly missing an object.

Don't be afraid to create these tiny classes to do little pieces of work--that's the magic of OO--you end up breaking it down until every method is very small and simple and every class small and understandable.

Another thing that should have been an indicator that something was wrong: in OO you have essentially no data--OO isn't about passing around data, a class needs to manage and manipulate it's own data internally, any data passing (including accessors) is a sign that you may need to rethink something..

Bill K