Question

How can operator bool() cause an error when declaring operator std::string in a class and also serving as an implicit conversion to string by itself?

#include <iostream>
#include <string>
using namespace std;

class Test {
public:
    operator std::string() { cout << "op string" << endl; return "whatever";}
    operator bool() { cout << "op bool" << endl; return true;}
};

int main(int argc, char *argv[]) {
    string s;
    Test t;
    s = t;
}

Answer 1

The problem you are facing (besides operator std::string() returning a bool) is that implicit conversions trigger when you want and when you don’t.

When the compiler sees s = t it identifies the following potential std::operator= matches:

// using std::string for compactness instead of the full template
std::string::operator=( std::string const & ); 
std::string::operator=( char );

Now, t is neither of them, so it tries to convert it to something that can fit and finds two paths: convert to bool that can be promoted to char or convert to std::string directly. The compiler cannot really decide and gives up.

This is one of the reasons that you want to avoid providing many different conversion operators. Anything that can be implicitly called by the compiler will eventually be called when you don’t think it should.

This article specifically deals with this problem. The suggestion is instead of providing a conversion to bool, provide a conversion to a member function

class testable {
   typedef void (testable::*bool_type)();
   void auxiliar_function_for_true_value() {}
public:
   operator bool_type() const {
      return condition() ? &testable::auxiliar_function_for_true_value : 0;
   }
   bool condition() const;
};

If an instance of this class is used inside a condition (if (testable())) the compiler will try and convert to bool_type that can be used in a condition.

EDIT:

After the comment on how the code is more complex with this solution, you can always provide it as a generic small utility. Once you provide the first part of the code, the complexity is encapsulated in the header.

// utility header safe_bool.hpp
class safe_bool_t;
typedef void (safe_bool_t::*bool_type)();
inline bool_type safe_bool(bool);

class safe_bool_t {
   void auxiliar_function_for_true_value() {}
   friend bool_type safe_bool(bool);
};
inline bool_type safe_bool(bool)
{
   return condition ? &safe_bool_t::auxiliar_function_for_true_value : 0;
}

Your class now becomes much more simple, and it is readable in itself (by choosing appropriate names for the functions and types):

// each class with conversion
class testable {
public:
   operator bool_type() {
      return safe_bool(true);
   }
};

Only if the reader is interested in knowing how the safe_bool idiom is implemented and reads the header they fill be faced with the complexity (which can be explained in comments)