Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2000-10-21 12:18:25

I stated and lost this argument nearly a year ago. But as the subject
has resurfaced, I'll restate it for the benefit of those that were not
involved in the discussions at that time:

There are (or should be) 10 fundamental classifications:


These correspond to the text in section 3.9 of the standard. In my
opinion, any type that one can generate, you should be able to throw at
these ten structs and have it test positive for one and only one test.
Admittedly, is_enum and and is_union will not work without either
compiler help, or extra attention from client code.

The fact that top level const is stripped off during template argument
deduction is not really pertinent to the discussion as these
classification structs could be very useful in meta-programming where
template argument deduction often does not play a role.

I don't claim to be insightful enough to be able to foresee all (any?) of
the applications where these structs might be useful. I have found a few
of them useful in my own work (mainly is_reference where top-level const
is not a concern anyway).

The way I read the standard, const int (or int* const) is an integral
type (or pointer type) that happens to be const, and so is_integral<const
int> (is_pointer<int*const>) should answer true. The standards
committee* agrees that const int is an integral type (but of course has
no opinion on what boost:is_integral should do).

[Footnote* If Mike Miller says it is so, you can take it to the bank.]

A possible alternative would be to expand the base set:

is_const_ pointer
is_volatile_ pointer
is_const_volatile_ pointer

That way you could still be able to say: Throw your type at this set of
classification structs and one and only one will answer true. But this
seems overly verbose to me when we could instead simply say (for example)

is_integral && is_const, instead of is_const_integral

FWIW, I feel the same way about is_extension and is_signed. I'd rather

is_integral && is_signed rather than is_signed_integral
is_integral && is_extension rather than is_extension_integral
is_integral && is_signed && is_extension rather than
and etc.

Of course one can get where you need to go with either design. So this
is purely a stylistic argument, not one of functionality. I personally
feel that the interface is simpler and easier to remember with fewer
non-combination names that can be combined with && (or || etc.) as needed.


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