Есть класс некоей variant переменной, у которой есть несколько установщиков значений разных типов:

void setValue(int);
void setValue(bool);
void setValue(float);
void setValue(std::string);

И почему-то на вызов setValue(“”) вызвался не setValue(std::string), а setValue(bool).

Это с чего бы?

Здравствуйте, Amygdala, Вы писали:

A>И почему-то на вызов setValue(“”) вызвался не setValue(std::string), а setValue(bool).

A>Это с чего бы?

Когда есть перегрузка, то компилятор должен как-то решить какой именно метод нужно вызывать.
Делается это примерно так: http://en.cppreference.com/w/cpp/language/overload_resolution

Метод с точным совпадением сигнатуры тут отсутствует, поэтому компилятор строит цепочки неявных преобразований, которые могут перевести "" в один из аргументов (про них смотри тут http://en.cppreference.com/w/cpp/language/implicit_conversion ).

Сразу выясняется, что в int и float этого сделать неявно нельзя никак, и соответствующие функции выбрасываются из рассмотрения.
Для оставшейся же пары возможные такие неявные пути преобразования:

const char(&)[1]   →   const char*   →  bool
const char(&)[1]   →   const char*   →  std::string

Оба этих преобразования ранжируются и второе оказывается строго хуже первого, ибо ему требуется обращаться к user-defined преобразованию, т.е. к вызову конструктора некого пользовательского класса string (и не важно что это std::string). Короче говоря: "а standard conversion sequence is always better than a user-defined conversion sequence".

Здравствуйте, watchmaker, Вы писали:

W>Короче говоря: "а standard conversion sequence is always better than a user-defined conversion sequence".
Офигенно лучше! Так лучше, что чтобы разрешить эту проблему предлагают втыкать сайф-буль идиому.

Здравствуйте, watchmaker, Вы писали:

W>Оба этих преобразования ранжируются и второе оказывается строго хуже первого, ибо ему требуется обращаться к user-defined преобразованию, т.е. к вызову конструктора некого пользовательского класса string (и не важно что это std::string). Короче говоря: "а standard conversion sequence is always better than a user-defined conversion sequence".

У меня, кстати, похожая проблемка. Есть перегруженный оператор << для iostream для wstring и для const wchar_t. Для wstring работает норм, а вместо второй версии вызывается для void* и печатает указатель. Нужно было только в одном месте, поэтому я просто явно сконструировал wstring и забил на разбирательства, но вообще интересно, как тут быть