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