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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk