On 6/18/2011 8:02 AM, Frédéric Bron wrote:
Then there is no way to predict if it is possible to compare lhs and rhs based only on their types.
Why do you write this ? Just because 0 can be an integer or a null pointer in C++ does not mean the above.
Here it is not literal 0 that can be an integer or a null pointer it is an const integer of value 0 that can also be considered as a null pointer... It seems to me that it makes a difference. If I tell you can you compare "int const" with "int*", you would probably answer "no" but if the "int const" is 0 the answer is false.
I understand that.
The general rule is that it is not possible so that this is what I propose to use for the type trait extension detecting the possibility to call comparison operators on given types.
To what does "this" refer in your previous sentence ?
I mean that I propose can_call_equal (or whatever name...)< int const, int *>::value to be false even if there is a possibility for comparing some int const with int*.
I agree with that. Initially you sounded like you would not handle 'pointer == const int' at all, and it was that to which I was objecting. However I was thinking... Is it not possible to test for const int x being 0 at compile time, possibly with MPL equal_to ? Then you could handle the case where the "int const" is 0, returning true when that is the case, otherwise returning false. In the MPL docs it says: "An integral constant object is implicitly convertible to the corresponding run-time value of the wrapped integral type." In your case the "int const x" is an integral constant object.