From: Howard Hinnant (hinnant_at_[hidden])
Date: 1999-12-07 10:53:09
John Maddock wrote on 12/7/99 7:58 AM
>>Yes, perhaps spell "built in type" as "fundamental type". I'm looking at
>3.9 in the standard, and the list there looks very similar to your list.
>Might be good to stick with the same terminology (if it works).<
>I was also coming to that conclusion - however there is a distinction
>between those types listed in the standard, and those that are provided by
>a particular compiler - for example long long, or the C99 complex types, it
>seems to be reasonable to define:
>is_fundamental<T>::value - for those types listed in the standard
>is_builtin<T>::value - for all compiler intrinsic types,
>by default just a thin wrapper around is_fundamental, but forms the basis
>for specialisations on other compiler supplied types.
Sounds good to me, though I haven't had the time the past couple of days
to study this as much as I would like.
>> template <typename T>
> struct call_traits
> typedef T value_type;
> typedef T& reference;
> typedef const T& const_reference;
> typedef const_reference param_type;
>Fair enough, but I think that you have more in here than just a
>"call_traits", I really like Steve's idea of splitting things down into
>"single-use" classes all with a common syntax - having said that the
>approaches are largely orthogonal - one can be synthesised from the other.
Steve's single-use classes seem to me to be the "fundamental level".
call_traits to me seems like a derived application. I meant to implement
call_traits in terms of remove_reference (and etc.) by now so I could
talk intelligently about that, but haven't had time. Maybe today...
But I still like the call_traits package with the four typedefs, even if
it is just syntax sugar for the "fundamental level". When I'm writing my
templated class and want to return something by reference that might or
might not be a reference itself, I don't want to have to stop and think:
"Should I use add_reference or remove_reference on the return type?" I
easily get confused! :-)
>> template <typename T>
> struct type_traits
> static const bool is_class = __is_class(T);
> static const bool has_trivial_default =
> static const bool has_trivial_copy =
> static const bool has_trivial_assign =
> static const bool has_trivial_destructor =
> typedef __strip_top_level_cv(T) cv_unqualified;
>The cv-unqualified member can be generated automatically without compiler
Yeah, I noted that. That's very neat!
>however it is sometimes useful to differentiate between const and
>volatile modified values: for example in a call_traits template you may
>want to treat "int" and "const int" the same - passing both by value, where
>as "volatile int" is better off being passed by reference - otherwise the
>volatile behaviour is lost.
Agreed. My type_traits was not fundamental enough.
>In the absence of compiler support, the
>type_traits class can at least act as the basis for full and partial
>specialisations. It may be nice though to think of a better name - I
>appreciate that "type_traits" has precedent, but maybe "class_traits" would
>be better - some other name would help to keep the class focused and avoid
>calls for every newly suggested feature to be added to the one class (as
>Dave pointed out a while ago).
If we go Steve's route with seperate structs, perhaps there is no
type_traits class? type_traits was meant to be fundamental description
of types which Steve may have obsoleted. Maybe now there are only
derived applications built upon the seperates (call_traits being a simple
example, ChooseInt.h being a much more complex example). Note that this
is food for thought, not a statement that implies I know what I'm talking
The biggest thorn in my side right now is not being able to differentiate
enums from classes and from unions. For example I would like to be able
to pass an enum into Steve's is_empty and have it generate false, instead
of a compile time error. I still don't see any way to do that without
compiler support. :-(
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk