Question

I’m having a strange behavior with an operator overloading in C++. I have a class, and I need to check if its contents are greater or equal to a long double. I overloaded the >= operator to make this check, my declaration is as follows:

bool MyClass::operator>=(long double value) const; 

I have to say that I also have a cast-to-long-double operator for my class, that works without exceptions only under certain conditions. Now, when I use this operator, the compiler complains that there’s an ambiguous use of operator>= and the alternatives are:

• Mine.
• The built-in operator>=(long double, int).

Now, how do I force the program to use my operator?

Answer 1

2015 update: Or, if you want to keep conversion ability using the (double)obj syntax instead the obj.to_double() syntax, make the conversion function explicit by prefixing it with that keyword. You need an explicit cast then for the conversion to trigger. Personally, I prefer the .to_double syntax, unless the conversion would be to bool because in that case the conversion is used by if(obj) even if it is explicit, and that is considerably more readable than if(obj.to_bool()) in my opinion.

---

Drop the conversion operator. It will cause troubles all the way. Have a function like

to_double() 

Or similar that returns the double value and call that function explicitly to get a double.

For the problem at hand, there is this problem:

obj >= 10 

Consider that expression. The builtin operator matches the first argument by a user defined conversion sequence for your type using the conversion operator long double(). But your function matches the second argument by a standard conversion sequence from int to long double (integral to floating point conversion). It is always ambiguous when there are conversions for two arguments, but not at least one argument that can be converted better while the remaining arguments are not converted worse for one call. In your case, the builtin one matches the second argument better but the first worse, but your function matches the first argument better but the second worse.

It’s confusing, so here are some examples (conversions from char to int are called promotions, which are better than conversions from char to something other than int, which is called a conversion):

void f(int, int); void f(long, long); f('a', 'a'); 

Calls the first version. Because all arguments for the first can be converted better. Equally, the following will still call the first:

void f(int, long); void f(long, long); f('a', 'a'); 

Because the first can be converted better, and the second is not converted worse. But the following is ambiguous:

void f(char, long); void f(int, char); f('a', 'a'); // ambiguous 

It’s more interesting in this case. The first version accepts the first argument by an exact match. The second version accepts the second argument by an exact match. But both versions do not accept their other argument at least equally well. The first version requires a conversion for its second argument, while the second version requires a promotion for its argument. So, even though a promotion is better than a conversion, the call to the second version fails.

It’s very similar to your case above. Even though a standard conversion sequence (converting from int/float/double to long double) is better than a user-defined conversion sequence (converting from MyClass to long double), your operator version is not chosen, because your other parameter (long double) requires a conversion from the argument which is worse than what the builtin operator needs for that argument (perfect match).

Overload resolution is a complex matter in C++, so one can impossibly remember all the subtle rules in it. But getting the rough plan is quite possible. I hope it helps you.