6

I recently came across a class like the following

class Foo {
public:
    Foo(std::string msg) {}
private:
    Foo(bool b) {}
};

I noticed that trying to create an object of this class by means of

Foo foo("blah");

causes a compilation error telling that Foo::Foo(bool) is private. Apparently, if the argument is not an actual std::string, the compiler prefers to use the constructor with the bool argument. On the other hand, if the private constructor is not given, above code compiles just fine.

Why is it that the "bool-constructor" has precedence over the "string-constructor" althogh the type of the passed argument does not fit to any of them? Is this just a matter of definition or does it have a deeper meaning and some good reason?

symphonic
  • 165
  • 2
  • 8

1 Answers1

7

The reason has to do with conversion operator precedence. Each of the calls includes an implicit conversion

  1. pointer -> std::string
  2. pointer -> bool

In this case #1 is a user defined conversion and #2 is a language / compiler defined one. User defined conversions have a much lower precedence and hence the other conversion is preferred.

Edit

Here is a similar question which has a much more in depth explanation of the precedence checks involved

conversion precedence in c++

Community
  • 1
  • 1
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • Is this in the spec somewhere? – Nick Mar 11 '13 at 16:04
  • 2
    @nick look in appendix B.2 – JaredPar Mar 11 '13 at 16:05
  • 1
    if by speck you mean the standard, yes, it's in **§13.3.3.2,2**: *When comparing the basic forms of implicit conversion sequences [...] - a standard conversion sequence [...] is a better conversion sequence than a user-defined conversion sequence* (`const char* -> bool` is a standard conversion sequence) – Arne Mertz Mar 11 '13 at 16:13