From: John Maddock (John_Maddock_at_[hidden])
Date: 1999-12-15 07:26:17
>Metrowerks is having trouble in this department too. Specifically
remove_const<int*const> is failing. I've sent a note to our front end
compiler engineer asking him about this. I don't claim to fully
understand chapter 14 so I have no comment on whether this represents our
compiler bug, or a remove_const bug. Though if gcc is handling it, it's
likely a compiler bug. I can work around the problem with these
additional specializations (and similarly for the other remove_xxx):<
OK, fair enough.
>I was surprised our compiler accepted these too. But it did, and even
specialized on them. After reading 3.9.3 it seems to me that they are
legal beasts. Though I've never seen one before, can't think of any use
whatsoever for them, and am not surprised if no other compiler allows
them. Whether or not such a construct is necessary or not is not that
interesting to me anyway. I'm excited about the _interface_ that we're
developing here, and its ability to handle anything a given compiler can
throw at it.<
Builder 4 accepts these also, but: look at 8.3.2 - these seem to be
specifically disallowed - they can only be introduced inadvertently via a
typedef or in template code - and when they are the cv-modifiers must be
discarded. This makes sense a cv-qualified reference is an oxymoron if
ever I saw one :-)
>I don't think I want my type_traits::class_type enumerated value. The
separates seem to do the same thing with just slightly different syntax.
But I do want all the functionality provided by the enumerated value (see
OK that simplifies things.
>Hmm... Metrowerks choked on is_empty as you have it. Complained about
the illegal use of an incomplete class at:
static const bool value = (sizeof(t) == sizeof(t2));
I worked around it by moving t and t2 to namespace scope.
static const bool value = (sizeof(empty_helper_t<T>) ==
Not sure if that represents a compiler bug or not, but I'm leaning toward
not a compiler bug.<
Whatever, it's easy enough to change.
>is_fundamental_type seems too course to me. I would like to be able to
tell integral types from floating point types. I would also like for cv
qualified "fundamental_types" to answer the same as cv unqualifed
fundamental_types: is_integral<int>::value == is_integral<const
int>::value == true. (same comment for is_void, is_array, and if the
silly compiler supports cv qualified references, is_reference too). I
see is_pointer already works for all cv-qualified versions, good!<
I was inconsistent here, however there is a good reason for *not* having
is_fundamental<T> evaluate to true for cv-qualified types - there are times
when you do need to differentiate built in types based upon whether they
are cv-qualified - for example has_trivial_copy<T>::value doesn't want to
be true for volatile builtins - copying memory (byte by byte) may not be
the same as regular access in that case.
>The implementation of is_fundamental_type (or is_builtin_type) really
seems to me to answer is_arithmetic (3.9.1, para 8). is_scalar might be
another useful query (3.9, para 10). The standard uses the word
"fundamental" to refer to the union of void types and arithmetic types
(which might also be a useful query).<
OK I agree with is_scalar<T>, the others seem to simple wrappers around
numeric_limits<T>, the only question is whether is_integer<T> etc should be
true for user defined types.
>I don't think that member_pointers should answer yes to is_pointer.
According to 3.9.2 they fall under a different category, and the use of
the word "pointer" is simply overloaded. I would like to be able to
distinquish between pointers and member pointers.<
I don't mind either way.
>I would like to see an is_union, even though like is_enum it will take
compiler support to implement. And then is_empty will need to take that
into account since unions can be empty too (don't ask me what you would
__do__ with an empty union! :-) ).<
>There is some inconsistency in the naming convention in that sometimes
"_type" is appended to the query and sometimes not. I would drop "_type"
Yep I always struggle with those names, sometimes I think one way, and
other times not :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk