Subject: Re: [boost] [type traits] Strange behaviour of comparison operators with pointers
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-06-20 19:35:01
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.