运算符> =重载的奇怪行为

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.

Answer 2

By providing an implicit conversion to a double you are effectively stating, my class is equivalent to a double and for this reason you shouldn't really mind if the built in operator >= for double s is used. If you do care, then your class really isn't 'equivalent' to a double and you should consider not providing an implicit conversion to double , but instead providing an explicit GetAsDouble, or ConvertToDouble member function.

The reason that you have an ambiguity at the moment is that for an expression t >= d where t is an instance of your class and d is a double, the compiler always has to provide a conversion of either the left hand side or the right hand side so the expression really is ambiguous. Either t 's operator double is called and the built-in operator >= for double s is used, or d must be promoted to a long double and your member operator >= is used.

Edit, you've updated your question to suggest that your conversion is to long double and your comparison is against an int. In which case the last paragraph should read:

The reason that you have an ambiguity at the moment is that for an expression t >= d where t is an instance of your class and d is an int , the compiler always has to provide a conversion of either the left hand side or the right hand side so the expression really is ambiguous. Either t 's operator long double is called and the built-in operator >= for long double and int is used, or d must be promoted to a long double and your member operator >= is used.

Answer 3

I assume you are comparing against a literal int , and not a long double :

MyClass o;

if (o >= 42)
{
   // ...
}

If that is the case both alternatives are as good/complex.

Using your operator long double() :

1. MyClass::operator long double()
2. built-in operator>=(long double, int)

Using your MyClass::operator>=(long double) :

1. built-in conversion int to long double
2. MyClass::operator>=(long double)

Answer 4

You've got long double in the declaration. Try changing it to double .

Answer 5

Your use of operator overloading combined with custom casting can be very confusing to users of your class. Ask yourself, would users of this class expect it to convert itself into a double, or be comparable with a double? Wouldn't having a .greaterThan(double) function achieve the same goal but without surprising the user?

I guess you could always explicitly cast your object to double before comparing, to avoid the ambiguity. But if I were you I'd reconsider the approach above and focus on writing code that's intuitive and behaves in an unsurprising manner, instead of fancy type-casting and operator overloading.

(Inspired by the FQA's wonderful rant about operator overloading )

Answer 6

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

Looks like you've defined:

bool class::operator>=(long double value) { return value >= classValue; }

And you are missing:

bool class::operator>=(double value)      { return value >= classValue; }
bool class::operator>=(int value)         { return value >= classValue; }

So the compiler can't decide which way to convert. (It's ambiguous.)

Perhaps a templated function (or method) would be helpful?

Watch out for situations where a>=b invokes different methods than b>=a .