Question

After a bug in my own code, where (in my opinion) the wrong overload got selected by the compiler, I have been digging for an explanation but can not find an easy one. I did find Herb Sutter’s GOTW 49 which deals with the issue of specialization. I also found a few questions on stackoverflow, but none could really explain the cause to me, nor provide me with good solutions.

I have a single class Foo, which can be constructed from a boolean. I found out (the hard way) that std::string can also be constructed from a bool (false).

I have three (template) methods with different arguments, as shown below. One method accepts “any” template argument, and two specializations, accepting a struct Foo and another accepts a string.

#include <string>
#include <iostream>

struct Foo
{
    Foo() : value( false ){ };
    Foo( bool v ) : value ( v ) { } 
    Foo( const bool& v ) : value( v ) { }

    bool value;
};

template< typename T >
void bar( const T& value )
{
    std::cerr << "template bar" <<  std::endl;
}

template< >
void bar< Foo >( const Foo& )
{
    std::cerr << "template bar with Foo" << std::endl;
}

template< typename T >
void bar( const std::string& )
{
    std::cerr << "template bar with string" << std::endl;
}

int main( int argc, char* argv[] )
{
    bar( false ); // Succeeds and calls 1st bar( const T& )
    bar< Foo >( false ); // Crashes, because 2nd bar( const std::string& )
                         // is called with false promoted to null pointer.

    return 0;
}

I have tested this with Visual Studio 2010 and with MinGW (gcc 4.7.0). GCC nicely gives a compile-warning, but msvc does not:

main.cpp:34:20: warning: converting 'false' to pointer type for argument 1 of 'std::basic_string< ... ' [-Wconversion-null]

Small update (in code): Even an explicit specialization with Foo does not work.\

Small update 2: The compiler does not complain about an “ambiguous overload”.

Small update 3: Some people answer that the two constructors of Foo accepting a bool, “invalidate” the selection of Foo. I have tested similar versions with only a single conversion constructor. These don’t work either.

Questions:

1. Why does the compiler try to call the string-argument version?
2. And why does the additon of <Foo> in the bar() call matter.
3. How can I prevent this from happening. E.g. could I force the compiler to select bar( const Foo& ) when a bool is input?
4. Alternatively, could I enforce a compile-error when someone calls bar< Foo >( false )?

Answer 1

Here are the answers to the four questions:

1. Why does the compiler try to call the string-argument version? Your class Foo has two constructors taking a bool which are ambiguous and, thus, converting bool to Foo is not considered (if you want to detect if a temporary or an lvalue is passed in, you can overload in C++ using bool&& and bool const& as parameter types). std::string can be constructed from a char const* and false can be promoted to a null pointer constant. A null pointer constant is syntactically a valid char const* but it is an illegal value and passing it causes undefined behavior.
2. And why does the additon of in the bar() call matter? When specifying the template argument you suppress template argument deduction and tells the compiler which argument to use. Specifying the template argument explicitly is the only way the overload of bar() taking a std::string can be chosen because T cannot be deduced for this template.
3. How can I prevent this from happening. E.g. could I force the compiler to select bar( const Foo& ) when a bool is input? The easiest way is to have the compiler deduce the template argument: the version of bar() s never chosen automatically by the compiler because the compiler can’t deduce the template argument. Alternatively, if you want to specify the template argument explicitly and only bool is a problem, you can add an overload taking bool and make the deduced version and the bool version delegate to the same internal function.
4. Alternatively, could I enforce a compile-error when someone calls bar< Foo >( false )? This would be easy using C++ 2011 by deleting the overload (see below).

To create a compile-time error when using bool with an explicitly specified template argument, you could add this overload:

template <typename T> void bar(bool) = delete;

Deleting function is available in C++ 2011.

The main question seems to be: If Foo and std::string can both be converted from bool, why is the std::string conversion chosen if bar<Foo>(bool) is called and the following overloads are available?

template <typename T> void bar(T const&);
template <>           void bar<Foo>(Foo const&);
template <typename T> void bar(std::string const&);

First, overload resolution chooses the primary template, ignoring any specializations). Since bar(std::string const&) as a more specialized interface than the version deducing the template argument, this version is chosen. The specialization of the first template is ignored in this stage. To make the use of Foo applicable as well, you could add

template <typename T> void bar(Foo const&);

and calling bar<Foo>(false) would be an ambiguity between the std::string and the Foo version.