Boost logo

Boost :

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:


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

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

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:


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


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


Boost list run by bdawes at, gregod at, cpdaniel at, john at