4

I'm using g++-4.6.1 --std=c++0x and getting a warning I can't seem to decipher with this bit of code:

#include <vector>
#include <tuple>

int main()
{
    std::tuple<std::vector<int>, int> t{ {1, 2, 3}, 10};
}

I get the following warning:

scratch.cpp: In function ‘int main()’:
scratch.cpp:6:55: warning: deducing ‘_U1’ as ‘std::initializer_list<int>’ [enabled by default]
/usr/local/include/c++/4.6.1/tuple:329:9: warning:   in call to ‘std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with _U1 = std::initializer_list<int>, _U2 = int, _T1 = std::vector<int>, _T2 = int]’ [enabled by default]
scratch.cpp:6:55: warning:   (you can disable this with -fno-deduce-init-list) [enabled by default]

Looking at the implementation:

template<typename _T1, typename _T2>
class tuple<_T1, _T2> : public _Tuple_impl<0, _T1, _T2>
    {
      typedef _Tuple_impl<0, _T1, _T2> _Inherited;

    public:
      //...

      template<typename _U1, typename _U2>
        explicit
        tuple(_U1&& __a1, _U2&& __a2)
        : _Inherited(std::forward<_U1>(__a1), std::forward<_U2>(__a2)) { }
    //...
}

It seems like it is complaining that it is forwarding from the initializer_list<int> (the {1, 2, 3} in my code) to the std::vector<int> which will be the first type in the std::tuple. This seems totally okay with me.

So my question is: What does this warning mean?

Luc Danton
  • 34,649
  • 6
  • 70
  • 114
Travis Gockel
  • 26,877
  • 14
  • 89
  • 116
  • I'll note that gcc 4.7 (the current development trunk) _doesn't_ give a warning for this code, even if you turn on all warnings and maximum strictness. Given that C++0x support has been improved substantially in 4.7 (in both the library and the compiler), it's quite possible that either this was a bug in 4.6's C++0x support, or there was a late change in the standard that affected this area. – snogglethorpe Nov 11 '11 at 00:07

2 Answers2

5

This is more of a guess than a quote from the standard, but I think it makes some sense.

The problem is that a brace-enclosed list can mean many things. It could be an initializer list, but as per uniform initialization it could also be any number of other things, such as aggregate initializers or simply constructor arguments.

Consider the following situation:

struct Bar { Bar(int, int, int){} };

void foo(const std::vector<int> & v);
void zoo(const Bar & v);

I can call both foo({1,2,3}) and zoo({1,2,3}). Because the argument type of both functions is known, there's no ambiguity. Yet foo's argument deduces as an initializer list, while zoo's argument is a uniform-initialization constructor call.

In the tuple situation, the problem is that all the involved types are templates. The constructor's argument type has to be deduced; it is not known at the time of the function call. It's true role only becomes apparent in the function body.

Since there can feasibly be many ways to construct the tuple member, this deduction may be ambiguous or just wrong, and so the compiler warns you that it is making an assumption.

In fact, you can construct a failure of this assumption very simply:

std::tuple<Bar, std::vector<int>> s{{1,2,3}, {1,2,3}};

This will fail to construct the first tuple member, because the brace-list is deduced incorrectly. The only "good" way of writing tuples is explicitly:

std::tuple<Bar, std::vector<int>> s{Bar{1,2,3}, std::vector<int>{1,2,3}};
Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
3

GCC is warning because deducing initializer lists is an extension. I assume the warning is here to be conformant as it should count as a diagnostic from the implementation.

Community
  • 1
  • 1
Luc Danton
  • 34,649
  • 6
  • 70
  • 114
  • So the brace-only argument isn't actually valid according to the standard? – Kerrek SB Nov 09 '11 at 15:48
  • @KerrekSB I actually have no idea as to what is the exact answer to *that*. `std::tuple` has a non-template constructor taking `(T const&...)`, so to answer your question, we have to consider why this constructor should not be picked over the template constructor, where the deduction happens. – Luc Danton Nov 09 '11 at 16:01