[boost] Re: call_traits/type_traits

From: Beman Dawes (beman_at_[hidden])
Date: 1999-12-15 11:53:34

At 11:23 AM 12/15/99 -0500, Howard Hinnant wrote:

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

I have only been skimming the discussion, but would guess that if
is_integral<const int> doesn't answer yes you will get endless user
complaints.

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

is_fundamental<T>::type sounds good to me too, FWIW.

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

Interesting idea!

boost::details looks good to me, but, hey, rel_ops has a long and
[in]glorious history:-)

Howard, you might want to repost your idea as a separate thread, so
people who are skipping the call_traits/type_traits discussion won't
miss it.

--Beman