27

I want to return some values from a function and I want to pack it in a tuple. So I have two possibilities for function declaration:

std::tuple<bool, string, int> f()
{
  ...
  return std::make_tuple(false, "home", 0);
}

and

std::tuple<bool, string, int> f()
{
  ...
  return std::forward_as_tuple(false, "home", 0);
}

These functions are equivalents? Between these functions which do you prefer?

Andy Prowl
  • 124,023
  • 23
  • 387
  • 451
Gian Lorenzo Meocci
  • 1,136
  • 2
  • 14
  • 23

2 Answers2

22

std::forward_as_tuple() creates a tuple of references. Since you are returning a tuple<bool, string, int> anyway, the two end up being equivalent in this case, but I think the first approach is clearer - using forward_as_tuple() when you are not forwarding anything is confusing.

Also, as mentioned by Sebastian Redl in the comments, make_tuple() would allow the compiler to perform copy elision - per paragraph 12.8/31 of the C++11 Standard, while forward_tuple() would not (since what it returns does not have the same type as the function's return type).

Andy Prowl
  • 124,023
  • 23
  • 387
  • 451
  • 4
    Also, more efficient. The first way can possibly use copy elision (if you wrap the string literal in a std::string constructor call), the second can't because it's not a normal copy. – Sebastian Redl May 23 '13 at 11:57
  • @SebastianRedl: Correct, worth mentioning. Thank you – Andy Prowl May 23 '13 at 11:58
7

I prefer,

std::tuple<bool, std::string, int> f()
{
  ...
  return { false, "home", 0 };
}

EDIT 1

The above code is actually compiling for me under clang/libc++ trunk. As @AndyProwl commented in comments section, this shouldn't since std::tuple constructor is explicit and returning through initialization-list syntax is in copy-initialization context, hence copy-list-initialization, which fails when an explicit constructor is matched.

I don't know the reason why clang/libc++ is passing, I suppose it to be a bug in libc++. Anyway, it's sad one can't do that for tuples...

I think I realized how sad (for me, at last) it's, generally. I was becoming used to that syntax, but one is forced to know beforehand whether or not the returning type contains an explicit constructor anytime for it to work.

EDIT 2

This is indeed a libc++ extension, for more information, checkout Howard Hinnant answer here: https://stackoverflow.com/a/14963014.

It's also currently open in the libc++ bug list: http://llvm.org/bugs/show_bug.cgi?id=15299.

This is the relevant proposal: Daniel Krügler, Improving pair and tuple.

In short this is what happens with libc++:

#include <tuple>
#include <string>

struct S
{
    explicit S(int) {}
};

int main()
{
    std::tuple<int, std::string> t1 = { 1, "hello" }; // ok
    std::tuple<std::string> t2      = "hello";        // ok
    std::tuple<int, S> t3           = { 1, 1 };       // fail: an *element* is to be constructed explicitly
}
Community
  • 1
  • 1
oblitum
  • 11,380
  • 6
  • 54
  • 120
  • 4
    I would also prefer it, but `std::tuple` has an explicit constructor, meaning the above won't compile – Andy Prowl May 23 '13 at 12:03
  • 4
    @AndyProwl Let's hope someone will bring [N3452](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3452.pdf) to some future standard. – Morwenn May 23 '13 at 12:06
  • 1
    @Morwenn: Didn't know about that, thank you. But actually, wouldn't be enough to make the constructor of `tuple` non-explicit? I don't understand why it has to be so. After all, `pair`'s constructor is not explicit – Andy Prowl May 23 '13 at 12:08
  • @AndyProwl, do you know why this compiles under clang -std=c++11 so? – oblitum May 23 '13 at 12:08
  • @AndyProwl Removing `explicit` from `std::tuple` constructor would solve the problem for `std::tuple`. At least, N3452 would solve it for any class in a function `return`. An no wonder you did not know about it, it does not appear in the mailing. – Morwenn May 23 '13 at 12:10
  • @chico: Huh? I tried it, and it does not compile (as I would expect, since the constructor of `tuple` is explicit) – Andy Prowl May 23 '13 at 12:11
  • Relevant http://stackoverflow.com/questions/9157041/what-could-go-wrong-if-copy-list-initialization-allowed-explicit-constructors – R. Martinho Fernandes May 23 '13 at 12:17
  • @chico: That's weird, in the current C++14 draft the constructor is still marked as `explicit`. I'd say it's a bug in the library implementation. – Andy Prowl May 23 '13 at 12:19
  • @AndyProwl Non-explicit variadic constructors also act as implicit conversions when the pack has a single element. I don't see how that would be a problem for tuple though... (And one could always single out that case with some SFINAE) – R. Martinho Fernandes May 23 '13 at 12:19
  • @R.MartinhoFernandes: I'm not sure I understand. Are you saying that should compile? – Andy Prowl May 23 '13 at 12:22
  • No, not according to the standard. I am just stating one reason why would one might want to make variadic ctors explicit. – R. Martinho Fernandes May 23 '13 at 12:23
  • @AndyProwl: actually, it's generally argued that conversion constructors (ie, any constructor that can be invoked with a single argument) should be marked `explicit`, much like conversion operators can now be marked `explicit`. However, there was a proposal to lift this rule in the case of return values, arguing that the type was explicit enough since it is spelled out in the function signature. I would guess that clang implemented this later proposal ahead of time. – Matthieu M. May 23 '13 at 12:43
  • @MatthieuM.: That's interesting, I didn't know that. So Clang is also ahead of C++14, cool :) – Andy Prowl May 23 '13 at 12:45
  • This days I'm using clang a lot most of the time with C++11 and I think I've done this more than once without knowing about the issue. – oblitum May 23 '13 at 12:46
  • 1
    @Andy not cool. That means I using clang+libc++ as my primary compiler if I want portable code can easily get annoying :( I wish compiler/library writers got their act together and made all such extensions opt-in. It's bad enough that I need to pass flags to get the compiler in "real C++" mode. It's much worse if even doing that does not give me the desired result. – R. Martinho Fernandes May 23 '13 at 12:46
  • @MatthieuM. it seems not to be the case, I've tested std::tuple copy-list-initialization without involving return from function, it keeps allowing it. – oblitum May 23 '13 at 12:50
  • @R.MartinhoFernandes: Once again I have to agree. I instinctively thought "it's cool" because I've often wanted to return a tuple by list-initialization, and the fact that a proposal exist and a compiler already implements it sounded promising. But you're right, standard compliance should be the priority number one, and if I really want that feature, I should pass a flag enabling that extension – Andy Prowl May 23 '13 at 12:51
  • @chico: good, I was looking into the mail archive and could not find anything about it :) Then it appears it would be a libc++ issue: a missing `explicit` on the constructor most likely. – Matthieu M. May 23 '13 at 12:55
  • @MatthieuM. In the end, it's a libc++ extension, check updated answer. – oblitum May 23 '13 at 18:36