[boost] Re: call_traits/type_traits

From: John Maddock (John_Maddock_at_[hidden])
Date: 1999-12-15 07:26:17

Howard -

>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 
below).<

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>) == 
sizeof(empty_helper_t2<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! :-) ).<

OK

>There is some inconsistency in the naming convention in that sometimes 
"_type" is appended to the query and sometimes not.  I would drop "_type" 
altogether:<

Yep I always struggle with those names, sometimes I think one way, and
other times not :-)

- John.