placing objects deriving from tuple into a vector in C++

Question

I want to create a struct with 3 values: a string and two ints. The string is mandatory, but either (or both) of the ints are optional and can default to -1 if not specified.

However, rather than use a struct, I thought I would try an std::tuple. In order to incorporate the optional-ness of the two ints, I setup a "Trio" class which inherits from std::tuple as below:

#include <string>
#include <tuple>

class Trio : public std::tuple<std::string, int, int>
{
    public:

    explicit Trio(std::string const & name, int val1 = -1, int val2 = -1)
    :
        tuple(name, val1, val2)
    {
    }
};

Then I go to test the Trio class by pushing some Trio objects into a std::vector:

#include <vector>
int main(void)
{
    std::vector<Trio> trios;

    Trio trio("trio1", 1, 1);
    trios.push_back(trio);

    return 0;
}

It gives me the following error in Visual Studio 2010:

>c:\program files (x86)\microsoft visual studio 10.0\vc\include\tuple(127):
    error C2664: 'std::basic_string<_Elem,_Traits,_Ax>::basic_string(const
    std::basic_string<_Elem,_Traits,_Ax> &)' : cannot convert parameter 1
    from 'const Trio' to 'const std::basic_string<_Elem,_Traits,_Ax> &'
 with
 [
     _Elem=char,
     _Traits=std::char_traits<char>,
     _Ax=std::allocator<char>
 ]
 Reason: cannot convert from 'const Trio' to 'const
 std::basic_string<_Elem,_Traits,_Ax>'
 with
 [
     _Elem=char,
     _Traits=std::char_traits<char>,
     _Ax=std::allocator<char>
 ]
 No user-defined-conversion operator available that can perform
 this conversion, or the operator cannot be called

Does anyone understand what I am doing incorrectly here? Is there something obvious that I am just not seeing? Am I, perhaps, severely abusing the usage of std::tuple?

Thank you,

Aaron

Answer 1

This is a bug of VC10.

VC10 complains because your class does not seem to have a copy constructor. Therefore, in order to copy values of type Trio, it tries to convert them into string, which is what the constructor you provide accepts (other arguments can be given default values). This is what the error you get complains about:

cannot convert parameter 1 from 'const Trio' to 'const std::basic_string<_Elem,_Traits,_Ax> &'

You can verify that this is indeed what is going on by adding a copy constructor explicitly and watch the error disappear:

Trio(Trio const& t) { *this = t; }

Now VC10 is satisfied because it sees a copy constructor, and the code compiles fine.

Nevertheless, when no copy constructor is explicitly provided by the user, your compiler should generate one implicitly. Per Paragraph 12.8/7 of the C++11 Standard:

If the class definition does not explicitly declare a copy constructor, one is declared implicitly. If the class definition declares a move constructor or move assignment operator, the implicitly declared copy constructor is defined as deleted; otherwise, it is defined as defaulted (8.4). [...]

Class Trio does not explicitly declare any copy constructor. According to Paragraph 12.8/2 of the C++11 Standard, in fact:

A non-template constructor for class X is a copy constructor if its first parameter is of type X&, const X&, volatile X& or const volatile X&, and either there are no other parameters or else all other parameters have default arguments (8.3.6)

Thus, the constructor you explicitly provide is not a copy constructor and should not inhibit the implicit generation of a copy constructor.

VC10 probably misinterprets the constructor you provide as a copy constructor and, therefore, does not generate one implicitly. Because of what written above, however, this behavior is a incorrect and qualifies as a bug.(*)

As a side note, your code compiles fine on Clang 3.2, GCC 4.7.2, and ICC 13.0.1.

UPDATE:

I tried to reproduce the problem with simpler data structures not involving std::tuple<>, and I failed. Therefore, the bug is not simply due to the fact that your constructor is misinterpreted by VC10 as an explicit copy constructor. However, this does not change the fact that VC10's behavior is incorrect.

Answer 2

Looks like this is just an issue in VS2010. I did not look to see if there is a bug filed about it or not. This will compile in both VS2012 and gcc-4.7.2