5 ms·
Implicit conversions come to mind. They don't need to interact with anything to be confusing. Consider this program: #include <iostream> using std::c
by implicit 15y ago
Implicit conversions come to mind. They don't need to interact with anything to be confusing.
Consider this program:
#include <iostream>
using std::cout;
using std::endl;
struct C {
int x;
C(int _x) : x(_x) {}
operator bool() const { return 0 != x; }
};
struct D {
float f;
D(float _f) : f(_f) {}
operator bool() const { return 0.0f != f; }
};
int main() {
C c(9);
D d(2.0f);
if (c == d) {
cout << "Equal" << endl;
}
return 0;
}
g++ 3.4.4 doesn't so much as warn that something is fishy here, even with -Wall.
Not only that, but c and d are considered to be equal.
- mnutt 15y agoMaybe it's just coming from a dynamic language, but it appears that you've overridden the bool operators to always return true. (except when you pass in 0 and 0.0) If you redefine how two structs of different kinds are compared, who is the compiler to say it's a problem?
- spullara 15y agoIn most dynamic languages 0 is false and anything else is true but it normally wouldn't use that information to coerce two values of different types to booleans before comparing them.
- mnutt 15y agoI'm only aware of php and javascript equating 0 to false. But at any rate in this case it's not equating 0 to false, it's comparing non-zero to zero and returning true. (as it should)
- burgerbrain 15y agoIn C, 0 evaluates to false.
- thedigitalengel 15y agoYou don't get a warning because the program is doing exactly what you asked it to do. You said a C with x = 0 is equal to 'true'. And you said a D with f = 0.0 is equal to 'true'. By transitivity of equality ...
- CJefferson 15y agoIn C++0x you can make those operator bool() explicit. Shouldn't have been there in the first place, and you still have to learn the difference between explicit and non-explicit operators, but at least now there is a way of making things behave.
- X-Istence 15y agoEven if they were explicit it wouldn't have "solved" his issue. Since he is using them in an if statement the C++ compiler would have considered that an explicit conversion anyway in C++0x mode. I don't have a C++0x compiler handy, or I would test it, but I do believe explicit is only meant for cases such as this: a + 1; where a has a bool() operator that returns 1 or 0, in the old mode if there was no way to get a to be a number it would look at the operator bool() see that it returns a number and use that. Using explicit on the bool() operator would make that illegal and most likely a compiler error.
- X-Istence 15y agoc and d are considered equal, you have overridden the boolean operators, what the code is actually calling on your if statement is: c.bool() == d.bool() In this case both will return true since they are non-zero, and thus the statement would be 1 == 1 Which is true; the compiler did exactly as you told it to do.
- anonymous246 15y agoYes, several people have already piled on. But if the compiler didn't say "Equal", then I would be claim it's confusing/inconsistent. Are you saying that the funtion YOU wrote to convert C/D to a bool shouldn't be invoked when YOU are using C/D as booleans?
- Dylan16807 15y agoIt's perfectly logical to use those functions when comparing them as booleans. But it's confusing that they're being used as booleans at all. They're converted because it will let the types match even though the conversion doesn't make much sense.