How to avoid 'implicit' calling of a one-parameter constructor in std::pair

Question

The original problem was how to work with std::map<std::wstring, std::wstring> > in a secure way because equal types of the key and the value are extremely error-prone. So I decided to create a simple wrapper for the value:

    struct ComponentName
    {
      std::wstring name;

      // I want to prohibit any implicit string-ComponentName conversions!!!
      explicit ComponentName(const std::wstring& _name) : name(_name)
      {
      }

      bool operator<(const ComponentName& item_to_compare) const
      {
        return name < item_to_compare.name;
      }
    };

    typedef std::map<std::wstring, ComponentName> component_names_map;

But the following code works well!

component_names_map component_names;
// Are you sure that ComponentName's constructor cannot be called implicitly? ;)
component_names_map::value_type a_pair = std::make_pair(L"Foo", L"Bar");

It works because the std::pair<std::wstring, ComponentName> copy constructor explicitly uses the string contructor of the ComponentName to assign the std::pair<std::wstring, std::wstring> instance. It's an absolutely legal operation. However it looks as an 'implicit' call of the ComponentName constructor.

So I know the reason of the problem, but how can I avoid this 'implicit' wstring-ComponentName conversion? The simplest way is to not declare the string constructor, but it makes ComponentName initialization inconvenient.

Answer 1

I think you can legally do this by adding a partial specialisation of std::pair for your type:

namespace std {
    template <typename T>
    struct pair<T,ComponentName> {
       typedef T first_type;
       typedef ComponentName second_type;

       T first;
       ComponentName second;
       // The rest of the pair members:
       // ....
       // Any trick you like to make it fail with assignment/construction from 
       // pair<std::wstring, std::wstring>
    };
}

Justification:

§ 17.6.4.2.1 sets out the basic rules for specialisations in the std namespace:

"A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited"

I can't see any explicit prohibition that would rule this particular case out, provided you filled out the rest of the class, within the bounds of § 20.3 .

---

Alternative, possibly legal approach:

Specialize std::is_constructible<ComponentName, std::wstring> such that value is false. This is listed as a requirement of both the assignment operator and the copy constructor for std::pairs of different types. I can't see any prohibitions from a quick scan of this either, but I can't find anything saying that implementations are required to check the requirements.

Answer 2

The problem (in C++03) is that most standard library implementations are not really standard conforming. In particular, the standard states that when a std::pair<T,U> is constructed from a different std::pair<V,W> the members are constructed by implicit conversions. The problem is that it is actually really hard (if even possible) to restrict that conversion in the implementation of the templated pair constructor, so current implementations perform explicit conversion of the arguments:

template <typename T, typename U>
struct pair {
    // ...
    template <typename V, typename W>
    pair( pair<V,W> const & p ) : first( p.first ), second( p.second ) {} 
};

I actually wrote a blog post about this particular case here, and for the sake of it I tried to provide the appropriate conversion constructors here, but the solution is not standard compliant (i.e. it has a different signature than those required by the standard).

Note: In C++11 (§20.3.2p12-14) this implicit conversion is also forbidden (From FDIS):

template<class U, class V> pair(pair<U, V>&& p);

Requires: is_constructible::value is true and is_constructible::value is true.

Effects: The constructor initializes first with std::forward(p.first) and second with std::forward(p.second).

Remark: This constructor shall not participate in overload resolution unless U is implicitly convertible to first_type and V is implicitly convertible to second_type.

The equivalent restrictions are present in p9-11 for the equivalent for template<class U, class V> pair(const pair<U, V>& p); (in case the types are not movable)

Answer 3

Simple:

enum FromString { fromString };

ComponentName( FromString, std::wstring const& aName)
    : name( aName )
{}