DECISION:
Instead of explicitly specifying make_pair<>() template arguments as follows:
std::make_pair< char, unsigned >( ch, number )
Just let them be deduced:
std::make_pair( ch, number )
EXPLANATION:
The rationale for this guide is found in the method for defining std::make_pair<>() and in the method of subtracting the template argument for universal references. From clause 20.3.3 / 8-9 of the C ++ 11 standard:
template <class T1, class T2> pair<V1, V2> make_pair(T1&& x, T2&& y);
Returns: pair<V1, V2>(std::forward<T1>(x), std::forward<T2>(y)); where V1 and V2 are defined as follows: let Ui decay<Ti>::type for each Ti . Then each Vi is equal to X& , if Ui is equal to reference_wrapper<X> , otherwise Vi is Ui . [Example: instead of:
return pair<int, double>(5, 3.1415926); // explicit types
C ++ program may contain:
return make_pair(5, 3.1415926); // types are deduced
-end example]
It is assumed that T1 and T2 . make_pair<>() setting the template arguments themselves, you get in the way of the make_pair<>() type inference mechanism to get the correct return type, forcing you to instantiate a function that accepts an rvalue reference to char and an rvalue reference to unsigned :
... make_pair(char&&, unsigned&&)
However, you do not provide rvalues in the input because ch and number are lvalues. This is what the compiler is complaining about.
ALTERNATIVE:
Also note that you can implicitly build a std::pair object that fully saves your call to make_pair<>() :
vec.push_back( { ch, number } );