12

I'm compiling some c++ code of a class MegaInt which is a positive decimal type class that allows arithmetic operations on huge numbers.

I want to overload operator bool to allow code like this:

MegaInt m(45646578676547676); if(m) cout << "YaY!" << endl;

This is what I did:

header:

class MegaInt { public: ... operator bool() const; }; const MegaInt operator+(const MegaInt & left, const MegaInt & right); const MegaInt operator*(const MegaInt & left, const MegaInt & right);

implementation:

MegaInt::operator bool() const { return *this != 0; } const MegaInt operator+(const MegaInt & left, const MegaInt & right) { MegaInt ret = left; ret += right; return ret; }

Now, the problem is if I do:

MegaInt(3424324234234342) + 5;

It gives me this error:

ambiguous overload for 'operator+' in 'operator+(const MegaInt&, const MegaInt&) note: candidates are: operator+(int, int) | note: const MegaInt operator+(const MegaInt&, const MegaInt&)|

I don't know why. How is the overloaded bool() causing operator+ to become ambiguous?¸

Thank You.

Well, everyone gave me great answers, unfortunately, none of them seem to solve my problem entirely.

Both void* or the Safe Bool Idiom works. Except for one tiny problem, I hope has a workaround:

When comparing with 0 like:

if (aMegaInt == 0)

The compiler gives an ambiguous overload error again. I understand why: it doesn't know if we're comparing to false or to MegaInt of value 0. None the less, in that case, I'd want it to cast to MegaInt(0). Is there a way to force this?

Thank You Again.

Improve this question
2

6 Answers 6

Reset to default
15

The C++ compiler is allowed to automatically convert bool into int for you, and that's what it wants to do here.

The way to solve this problem is to employ the safe bool idiom.

Technically, creating an operator void* is not an example of the safe bool idiom, but it's safe enough in practice, because the bool/int problem you're running into is a common error, and messes up some perfectly reasonable and otherwise correct code (as you see from your question), but misuses of the void* conversion are not so common.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

+1: Linking to the safe bool idiom makes this the best answer by far.
Both void* and safe bool idiom work to solve my problem 99%. Is there a way that it also works doing if(aMegaInt == 0), since now this becomes ambiguous with testing for false, or for MegaInt(0)?
@didibus: safe bool idiom, when done right, doesn't make that ambiguous. Did you try writing operator==(int, MegaInt) and operator==(MegaInt, int)?
Karisson remarks, "comparisons ... imply an equivalence relationship that can never exist". Certainly true == true. What am I missing?
4

The wikipedia entry on explicit conversion operators for C++0x has a decent summary of why you see this error pre-C++0x. Basically, the bool conversion operator is an integral conversion type, so it will be used in an integral arithmetic expression. The pre-C++0x fix is to instead use void * as the conversion operator; void * can be converted to a boolean expression, but not to an integral expression.

Improve this answer

3 Comments

Though I don't think having to explicitly convert to bool is really much nicer, if that's the C++0x solution to the problem.
@Omnifarious: they came up with a custom kludge in the standard just for this situation :p. "However, language contexts that specifically require a boolean value (the conditions of if-statements and loops, as well as operands to the logical operators) count as explicit conversions and can thus use a bool conversion operator."
That's if C++0x ever gets released. Wasn't it renamed C++1x, because they missed the 2000-2010 schedule lol.
2

As Erik's answer states, the problem here is that by providing an implicit conversion to bool you are opening the door to expressions that can mean multiple things; in this case the compiler will complain of ambiguity and give your an error.

However, note that providing an implicit conversion to void* will not let you off the hook; it will just change the set of expressions which present a problem.

There are two airtight solutions to this issue:

  • Make the conversion to bool explicit (which can be undesirable if the class represents an entity with an intuitive "true/false" value)
  • Use the safe bool idiom (this really covers all bases, but as many good things in life and C++ is way too complicated -- you pay the price)
Improve this answer

Comments

1

The problem is that bool can freely convert to int. So the expression MegaInt(3424324234234342) + 5; can equally validly be interpreted this way:

(bool)(MegaInt(3424324234234342)) + 5;

or:

MegaInt(3424324234234342) + MegaInt(5);

Each one of those expressions involves one user defined conversion and are equal in the eyes of the compiler. Conversion to bool is highly problematic for this reason. It would be really nice to have a way to say it should only happen in a context that explicitly requires a bool, but there isn't. :-/

The conversion to void * that someone else suggests is a workaround, but I think as a workaround it has problems of its own and I wouldn't do it.

Improve this answer

Comments

0 
MegaInt(3424324234234342) + 5; MegaInt + int;

Should the compiler convert your MegaInt to an integral (bool is an integral type) or the integer to MegaInt (you have an int constructor)?

You fix this by creating an operator void * instead of an operator bool:

operator void *() const { return (*this != 0) ? ((void *) 1) : ((void *) 0); }

Improve this answer

Comments

0

Others have mentioned the Safe Bool Idiom. However, for objects like yours it is a bad idea to add all this nasty, special logic when you want full algebra support anyway.

You're defining a custom integer type. You get far more for your effort by defining "operator==" and "operator!=", then implementing "operator bool()" as something like:

operator bool() { return (*this != 0); }

Just from those 3 functions you get all of the "if" idioms for integers, and they'll behave the same for your custom ints as the built-in ones: "if(a==b)", "if(a!=b)", "if(a)", "if(!a)". Your implicit "bool" rule will also (if you're careful) work intuitively as well.

Besides, the full "Safe Bool Idiom" is unnecessary. Think about it- the only time you need it is "1) comparison of 2 objects is ill-defined or undefined, 2) cast to (int) or other primitive types needs to be protected and 3) object validity IS well-defined (the actual source of the returned bool)."

Well, 2) is only a consideration if you actually wish to SUPPORT casting to a numeric type like int or float. But for objects that have NO well-defined notion of equality (# 1), providing such casts unavoidably creates the risk of the very "if(a==b)" logic bombs the idiom supposedly protects you from. Just declare "operator int()" and such private like you do with the copy ctor on non-copyable objects and be done with it:

class MyClass { private: MyClass(const MyClass&); operator int(); operator long(); // float(), double(), etc. ... public: // ctor & dtor .. bool operator==(const MyClass& other) const { //check for equality logic... } bool operator!=(const MyClass& other) const { return !(*this == other); } operator bool() { return (*this != 0); } };
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.