Re: [boost] is_pointer Bug

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-10-17 15:36:40

>However - changing it now requires a big change (more or less a complete
>rewrite) of many of the classes in the header, this is not just an
>is_pointer issue.

I think most of it could be done with the addition of more specializations.

>I am now more or less convinced by Steve Cleary's
>argument: arithmetic types, pointers, arrays and references, are defined
>first as non-cv-qualified types.  The notion of cv-qualification comes
>later.

I'll concede that the letter of the standard implies that const int's are
not integral types and and by analogy const pointers are not pointers.
However I find it difficult to believe that this is what the committee
intended: the language is ambiguous for pointers and the other types in
3.9.2 and it leaves const types in a rather weird state. What for example
is a const int? It's distinct from int, but it's not a signed integer type,
and it's not an integral type. It's apparently just one of an infinite
family of const types.

>Finally a cv-qualified int is not an int (for example you can not
>assign an integral expression to it if it is const-qualified),

It's clear that it's not an int. The question is whether we want to follow
the letter of the standard or whether we decide that the standard is not a
useful guide for these cases.

>types that
>are cv-qualified in general require special handling, I think that it is
>defensible to exclude these by default.

I dunno about this. It seems to me that if you need to special case const
types then you'll write code to do so using is_const and remove_const. If
special casing isn't required it'd be nice to not have to muck around with
remove_const.

  -- Jesse