views:

150

answers:

1

tuple in boost and TR1/c++0x provides a convenient (for the writer of the function) method to return two values from a function--however it seems to damage one major feature of the language for the caller: the ability to simply use the function to initialize a variable:

T happy();
const auto meaningful_name(happy()); // RVO means no excess copies

but for:

tuple<T,U> sad();

we either have to surrender the ability to pick a meaningful name for our return values, and use get<n>() everywhere:

const auto two_unrelated_things(sad());

or make a temporary:

const auto unwanted_named_temporary(sad());
const auto one_name(get<0>(unwanted_named_temporary));
const auto two_name(get<1>(unwanted_named_temporary));

or switch from initialization to assignment, which only works when the types are assignable, and breaks auto:

tuple_element<0, decltype(sad())>::type one_mutable; // there might be a less
tuple_element<1, decltype(sad())>::type two_mutable; // verbose way
tie(one_mutable,two_mutable) = sad();

or do something unnatural to a local class:

const struct ugh { 
  ugh( decltype(sad()) rhs ) : one_name(get<0>(rhs)), two_name(get<1>(rhs)) {}
  const tuple_element<0, decltype(sad())>::type one_name;
  const tuple_element<1, decltype(sad())>::type two_name;
} stuff(sad()); // at least we avoid the temporary and get initialization

Is there a better way? I'm using VC10 compatible constructs above, would anything in full c++0x or boost help?

Ideally it would:

  • allow me to use initialization, not just assignment
  • let the caller pick the names for the returned-into variables
  • not make extra copies
  • work for both stack variables and class members
  • possibly be a big crazy template library, but have sane syntax for caller and function writer
+1  A: 
std::tuple<Type1, Type2> returnValue = sad();
Type1& first = std::get<0>(returnValue);
Type2& second = std::get<1>(returnValue);

I'm not sure what your fourth bullet means, but that satisfies all the rest.

*edit: Based on your comment above, I figured out what you meant by the fourth bullet.

struct Object {
    Object(const std::tuple<Type1, Type2>& t) : value(t) { }
    Type1& First() { return std::get<0>(value); }
    Type2& second() { return std::get<1>(value); }
private:
    std::tuple<Type1, Type2> value;
}

Modify as needed.

You could also just not use std::tuple at all if the returned values are so unrelated that you have to split them up in order for them to be used reasonably. People have gotten by for years returned structs with reasonably named fields, or by accepting reference parameters for output.

As an aside, you seem to be in love with auto. Don't be. Its a great feature, but this is not the way it should to be used. Your code is going to end up illegible if you don't specify types from time to time.

Dennis Zickefoose
As I think about the "class member" bit, is this even a situation where you can elide all the copies? I think you're going to end up copying `value` at least once under any circumstances, which will obviously require copying its members at least once. So you probably might as well just store the values directly and forget about storing the tuple at all.
Dennis Zickefoose
I agree with not using `std::tuple` when it isn't appropriate -- I'm just worried that it'll become idiomatic and make code less understandable and full of `get<n>(sometuple)`That said, it looks like I worry too much about extra copies: `tie(a,b) = sad()` in a constructor successfully elides all the copies of the tuple members when sad() does `return make_tuple(...)`. Maybe the lesson is "`const` data members are a hassle".
BCoates
@bcoates: Regarding mis- and overuse of tuple. Standard library is a bit guilty itself when it represents ranges as `pair<iterator, iterator>`. OTOH, boost is employing a superior alternative: `iterator_range<iterator>` with a `begin()` and `end()` method. A range is not an abstract pair, `first` and `second` do have a concrete meaning! - I don't think one should go very tuple-happy in non-generic code.
UncleBens