[boost] Re: call_traits/type_traits

From: Howard Hinnant (hinnant_at_[hidden])
Date: 1999-12-15 11:23:41

John Maddock wrote on 12/15/99 7:26 AM
>>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.

Confirmed compiler bug.  Will be fixed in our next major release.

>>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 :-)

Right!  Thanks for the _reference_. ;-)

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

I was about to agree with you, but I think I'm changing my mind back 
again.  Here's what's going through my pointy little head:  Given any 
type T, I would like to be able to classify it into one (and only one) of 
the 10 "bottom-level" categories:

is_integral
is_floating
is_void
is_array
is_pointer
is_reference
is_enum
is_class
is_union
is_member_pointer

Admittedly one could do this by saying 
is_integral<remove_cv<T>::type>::value.  But one could also implement 
has_trivial_copy using the is_const query to do the differentiation.

Which is the proper direction?  I think I'll need to play with both 
implementations before I decide for sure.  But the way I'm feeling right 
now (shooting from hip) is that a const int _is_ an integral type, and so 
is_integral<const int> should answer yes.

>>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'm viewing this as an implementation of 3.9, instead of a wrapper around 
numeric_limits.  I can imagine situations where you might want to plug a 
UDT into numeric_limits (BigNum or whatever), but still might want to 
differentiate BigNum from int based on the defintions in 3.9.  Here it 
says int is integral and BigNum is a class -- even though a 
numeric_limits<BigNum> makes perfect sense.  For example, I can derive 
from BigNum, but I can't from int.  is_empty needs that kind of 
information.

>>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 :-)

I had another thought after I wrote that.  Let me float it out there:

I liked your consistent use of "value" for bool and "type" for typedefs.  
But if we remove the trailing "_type" from (say) is_fundamental_type, 
usuage looks like:

is_fundamental<T>::value

Ok, not bad, but this doesn't look too bad either:

is_fundamental<T>::type

When I read it out loud, it sounds kinda' nice.  You can still tell it is 
a bool because of the "is_" prefix.  Just a thought...

Another thought:

I would imagine that little implementation namespaces are (or soon will 
be) common in boost libraries.  Namespace aware browsers might have the 
ability to hide and show, based on a namespace name.  Instead of 
presenting a zillion little implementation detail namespaces to such a 
browser, how 'bout if boost libraries standardize on a common 
"implementation detail" namespace.  Then it would be easy for the user of 
a namespace aware browser to "show boost", but hide "boost::details".  We 
could prototype such a thing with the work in this thread, and if it 
seems reasonable, propose it in a separate thread.

Assuming this is a good idea, here are a few suggested names for this 
nested namespace:

1.  boost_implementation
2.  implementation
3.  imp
4.  details
5.  rel_ops

I think 1 and 2 are too long, making it too hard to read the 
implementation of a boost lib.  3 is a little short and ambiguous.  I 
like 4 the best.  But I think 5 is really funny.  We all know how 
effectively std::rel_ops hides its contents from client code! :-)

-Howard