Returning multiple values from functions in C++

http://eli.thegreenplace.net/2016/returning-multiple-values-from-functions-in-c/

by ingve • 10 years ago

78 62 10 years ago

eli.thegreenplace.net

The getline case (boolean and possible value) really wants a type like Haskell's "Maybe" or Rust's Option: a type that either contains nothing or a value.

halayli• 10 years ago

There's std::optional that's still in the works:

http://en.cppreference.com/w/cpp/experimental/optional

jepler• 10 years ago

Unfortunately the currently available solution (boost::optional) performs enough worse that the difference can be measured in a simple implementation of "wc -l". Consider the following code:

    #include <iostream>
    #include <string>
    #include <boost/optional.hpp>

    using namespace std;
    using namespace boost;

    optional<string> getline_(istream &st) {
        std::string line;
        if(getline(st, line)) return line;
        return none;
    }

    int main() {
        int lines = 0;
        while(getline_(cin)) lines++;
        cout << lines << "\n";
    }

    using namespace std;
    int main() {
        int lines = 0;
        string line;
        while(getline(cin, line)) lines++;
        cout << lines << "\n";
    }

Run on an input file of 172,544 lines (the GPL-3 license repeated 256 times), the version using "optional" takes 400ms and performs 1,077,504(!) heap allocations, while the more standard version takes just 280ms and performs just 8 allocations.

Of course, "wc -l" (GNU) takes just 9ms, so clearly this isn't a great program either way--but it does serve to show that boost::optional can be a surprising performance sink compared to using a bool return value + out parameter.

(tests on debian jessie amd64, i5-3320M @ 2.6GHz, g++ 4.9 -O3, boost 1.55.0.2)

mavam• 10 years ago

+1 for Having Measured It.

The basic getline interface removes heap pressure by reusing the same string over and over, even though semantically the optional<string> approach may look cleaner. Eric Niebler showed a while ago (I can't remember where) that this API lends itself perfectly to ranges, and can provide both a reasonable interface without sacrificing performance. IIRC, the API looked somewhat like this:

    for (auto& line : getline_range(cin))
      f(line); // do something with line, e.g., parse.

The semantics are: iterate over standard input until EOF or error and let the range keep (and reuse) the string internally while exposing it as const-reference by dereferencing.

imron2• 10 years ago

That's not the fault of optional though. It's because with the optional version you're creating (and destroying) a new string each iteration of the loop.

Something like this (untested) should be much closer to the non-optional version:

    #include <iostream>
    #include <string>
    #include <boost/optional.hpp>

    using namespace std;
    using namespace boost;

    optional<string&> getline_(istream &st, string& line) {
        if(getline(st, line)) return line;
        return none;
    }   

    int main() {
        int lines = 0;
        string line;
        line.reserve( 1024 );  //1024 should be long enough for any line
        while(getline_(cin, line )) lines++;
        cout << lines << "\n";
    }

rav• 10 years ago

In this case, passing the std::string to std::getline by reference is more than just an "out parameter": it is the buffer in which the result should be stored. Of course this will be more efficient than allocating a new buffer for each line -- and that is a good reason why this particular interface would be worse off with multiple return values.

The std::unordered_map::insert example in the article is an excellent example of an interface with multiple return values: it returns a pair (iterator, bool) of an iterator to the given key and a bool indicating if the iterator is to a newly inserted key-value pair or if it was the key-value pair already stored in the map. Neither the iterator nor the bool owns a buffer like in the std::getline example, so the std::getline out parameter design is not needed here.

jimjimjim• 10 years ago

I know it's mentioned specially in the article but the C programmer in me immediately wants to use structs. They don't need to be complex or long lived or even initialized. And as a bonus there's no heap involved anywhere. Either that or just bail out of c++ and use go.

wall_words• 10 years ago

std::tuple is essentially an "anonymous" struct -- there's no allocation involved

kzhahou• 10 years ago

But the members inside don't have proper names.

oselhn2• 10 years ago

I prefer to use generic structures (tuples, pairs etc.) or return proper type. One time structs are usually redeclared on multiple places. It is really hard maintain such code.

nwmcsween• 10 years ago

Well it's not really one time use than is it. Compound literals are your friend.

mbel• 10 years ago

    > One time structs are usually redeclared on multiple places. It is really hard maintain such code.

Well, if you don't need forward declarations, you can define structs inline in function signature:

    #include <stdio.h>
    
    struct ret { int a; int b} hello(int c) {
        return (struct ret){ c, c + 1 };
    }
    
    int main(int argc, char **argv) {
        struct ret result = hello(2);
        printf("%d %d", result.a, result.b);
    }

I'm not sure how portable it is though, works in gcc and in whatever ideone is using: https://ideone.com/bgZUPS

wingerlang• 10 years ago

Either that or just bail out of c++ and use go

So either use structs or totally change language? That doesn't really make sense.

eps• 10 years ago

Yeah, same here, a president of a local Duff's decice fanclub, but you have to admit that proposed C++ 17 feature is pretty nice:

    ... foo()
    {
        return { 1, "bar", false };
    }

    auto { i, s, b } = foo();

It's a syntax sugar, granted, and they could push it further by adopting tuples as a native language construct with some shorthand notation (e.g. [...]), but the idea is nice.

stinos• 10 years ago

Especially when being used to Python this would be a very welcome addition

tdsamardzhiev• 10 years ago

Sweet!

Although I still cannot believe it took C++ like 30 years to come up with this.

m_mueller3• 10 years ago

Instead of markers, I like to use typedefs instead. Here's an example how this would look like in a HPC related program. Basically, if you know Fortran, you know where this is coming from.

    typedef const double * const __restrict__ IN;
    typedef double * const __restrict__ OUT;
    typedef const int INT_VALUE;
    typedef const double FP_VALUE;

    void diffuse_c(
        OUT runtime_total_s,
        OUT runtime_boundary_s,
        OUT thermal_energy_updated,
        IN thermal_energy,
        INT_VALUE nx,
        INT_VALUE ny,
        INT_VALUE nz
    );

Aeolos• 10 years ago

I can't be the only one who finds "INT_VALUE" both superfluous and unnecessarily ugly?

m_mueller3• 10 years ago

You're right, I have been thinking about this naming as well. I think in this context, "INT_PARAM" would be better. I like to typedef it because this way it's easier to replace with a hardware specific integer type later on if I decide to do so. Anyways, the "VALUE" naming is coming from Fortran, which is by default pass-by-reference, so you use it to get pass-by-value.

Edit: Thinking about it some more, "INT_VALUE" still makes sense - it makes it clear that this specific symbol should be accessed as a value, not as a pointer. Doing this reminds me that I'm (probably) imposing more register pressure by passing by value. In general I'd probably pass a const int * const pointer here, but in this specific case I needed values because of some CUDA specific limitation.

rileymat22• 10 years ago

I am a bit surprised exceptions were not mentioned in the context of returning an error value.

stevedonovan• 10 years ago

It is certainly a good way to _avoid_ throwing exceptions in a public API.

eliben• 10 years ago

The idea was to show things that actually make sense as return values / statuses rather than exceptions. I surely wouldn't throw an exception for "getline reached EOF"

rileymat22• 10 years ago

Yeah, I am not for overusing exceptions, but languages like python make creative use of exceptions. For instance the generator syntax raises an exception when it is done. Interestingly, you can make a generator to go through the lines in a file, and use that when you are at the EOF.

junke7• 10 years ago

Ada has in, out and in/out parameters which adds a little more semantic to C and C++'s pointer parameters.

Author mentions Common Lisp's multiple values, and one of the main feature of multiple values is that they are optional: the caller does not need to use secondary values. Even though floor returns 2 values, the following is a valid expression:

   (+ (floor x) 2)

Only the primary value is used. A compiler typically generates code that use registers: the program does not allocate memory to wrap return values in list or a structure (all values are still computed, but secondary values are often additional data that a function needs to compute to determine its primary result).

giancarlostoro• 10 years ago

C# has out if I remember correctly. Haven't used it in months (C# that is) but it pretty much does the job as far as I've used it.

adwf5• 10 years ago

Sometimes Lisp can get annoying though. I've used libraries where a function might return 5-6 values and I only need the first and last. I need to bind all of them and then (declare (ignore...)) the useless bits otherwise I get compiler warnings.

It's an annoyance, because I always feel the general ethos of Lisp is to eliminate tedious typing and multiple value returns frequently add a lot of cruft.

junke7• 10 years ago

I agree that Lisp is not always terse, which surprised me at first too. You can abstract many constructs and eradicate redundancy, but at some point, your only chance of being terser is to use reader macros. However, doing so might not be a good idea either.

There are libraries out there that provide syntactic sugar for Common Lisp, which is often discarded because (i) they define their own "ghetto" dialect of Lisp (ii) it is in fact not very important to waste a character or two. Aesthetics alone is not a goal.

For multiple values, you might still use a list instead, in which case you are back to the usual way of accessing data:

   (let ((list (multiple-value-list (get-decoded-time))))
     (format t "Year: ~A~%Seconds: ~A" (sixth list) (first list)))

If you only want to access a particular value, use "nth-value" (not possible in your example, of course).

lispm8• 10 years ago

Common Lisp is a programmable programming language.

You need to hack around it. Don't like it? Improve it. Sketch:

    (defun make-vars (vars &aux syms)
      "creates uninterned symbols for vars named NIL.
    Returns a list with those replaced and a list of the new syms."
      (values (loop for var in vars
                    if (eq var NIL)
                    collect (let ((sym (gensym "ignore"))) (push sym syms) sym)
                    else collect var)
              syms))

    (defmacro multiple-value-bind-some (vars form &body body)
      "Similar to MULTIPLE-VALUE-BIND, but variables named NIL will be ignored."
      (multiple-value-bind (vars syms) (make-vars vars)
        `(multiple-value-bind ,vars ,form
           (declare (ignore ,@syms))
           ,@body)))

Example

    (defun foo (x)
      "returns five values"
      (values x (* x 2) (* x 3) (* x 4) (* x 5)))


    (defun test ()
      (multiple-value-bind-some (a nil nil nil b)
          (foo 10)
        (list a b)))

matt42• 10 years ago

The problem with deconstructing a tuple is that you can easily make mistake about the order of its members. The struct is a much better solution to me, and you can go over the problem of the weirdly named one-off struct by using the iod library (https://github.com/matt-42/iod):

  foo() { return D(_id = "test", _age = "42" }; }

  auto r = foo();
  std::cout << r.id << r.age << std::endl;

ericfrederich• 10 years ago

Meaningful names would be nice.

In C++ iterating over a map items you get a pair with ->first() and ->second() methods instead of key / value.

Python has named tuples which can work both ways.

qwertyuiop9247• 10 years ago

For a moment, I thought they had added true multiple value return to C++. I am sooo glad they didn't. The lisp folks added it way back, and it has been an ugly scar on the language ever since. Why do real multi-value returns suck? because they don't compose well, they're awkward as all heck to use, and require wrapping certain function calls in really weird constructs. The PROPER way to do multiple values is to return a data structure and pattern match against it. Of course, lisp has support for this, multi-value return was just an optimization hack. WHICH YOU SHOULD NO LONGER USE!

masklinn2• 10 years ago

It's funny, your comment uses "true MRV" for language-level special-casing by opposition to a matched (or even just python-style unpacked) data-structure, whereas I've always thought the latter was "true MRV".

Either way, we do agree on MRV being a language-level special case being a hack. Even PHP isn't that bad — though the unpacking is macro-ish bleh.

junke7• 10 years ago

If you wrap your data in a list or a tuple, it is still a single value. It makes sense to talk about true MRV in languages that support it, like Ada, Forth and others... (https://rosettacode.org/wiki/Return_multiple_values)

junke7• 10 years ago

Multiple values are not "just" an optimization hack, they are designed to be convenient to use. I don't know which construct you find "weird". Multiple-value-bind is a descriptive name which is long to type but this does not matter (type m-v-b + auto-complete).

Typical example: you read a line in a file. The line you get is terminated either by a newline character or by the end-of file. The implementation of read-line[1] must know if you reached end of file or not, but most of the time, you don't care about it. Sometimes, you want to know, and then you can take the secondary value (missing-newline-p). I like the fact that I can focus on the primary value without caring about other ones when I want.

[1] http://clhs.lisp.se/Body/f_rd_lin.htm

JoeAltmaier• 10 years ago

Sounds like methods could also add special-purpose multiple values later, without impacting existing callers. Which is nice too.

qwertyuiop9247• 10 years ago

Maybe this is different in CL, but in scheme, if you're using a procedure that returns multiple values, there is no default return, or wrapping the multiple values into a list: You have to use call-with-values, any number of srfis providing sugar, most commonly srfi-8, although 11 and 71 also exist, and without the sugar, god knows how many lambdas. EVERY. SINGLE. TIME. You want to call a function that returns multiple values.

lispm8• 10 years ago

Which is clearly nonsense. Multiple values have been extremely useful and there are several code bases in Common Lisp which make extensive use of it.

qwertyuiop9247• 10 years ago

Yes. They are useful. So is goto, so are continuations. MVR isn't the unforgivable sin that those things are, but imo, it makes your codebase uglier.

Returning multiple values from functions in C++

Related Stories