[boost] Re: Type Traits, Take Two

From: scleary_at_[hidden]
Date: 2000-01-11 09:31:35

> From: John Maddock [mailto:John_Maddock_at_[hidden]]
> > But regardless, does it matter? Can someone give a practical problem,
for
> > which this sort of information is needed to provide a correct solution?
> >
> > While traits are a good thing, and a general traits class would be
useful,
> > this all smacks of a solution looking for a problem.
>
> > There are two principal uses: optimisation and assertion checking.
> >
> > Optimisation:  If type T has a trivial destructor then don't
> > bother calling destructors on T.
>
> Can't the compiler optimise away a trivial destructor for itself? In any
> case, I suspect that this could be a lot of machinery (and complexity, and
> possibly unmaintainability) for minimal gain (roll out the standardx quote
> "premature optimisation is the root of all evil").
>

As has already been pointed out, compilers may have problems optimizing away
a loop containing trivial destructors.

The original STL had three considerations: orthogonality, efficiency, and a
firm theoretical base.  I believe what optimization can be done in a library
should be done.  This is not "premature", IMO, because end users hardly
_ever_ modify library code!  Therefore, any optimization we can see to do
_we_ should do.  That is why, after type_traits is stable, I will recommend
that we specialize when necessary for every other single class in Boost.

>
> > Dicission Making:  What is the optimal way to pass T as an argument - as
> > const T (by value) or const T& (by reference) - in other words to
implement
> > call_traits.
>
> I'm not against call_traits. But why not just implement it, instead of
> spending ages splitting hairs over what precisely is a built-in integer
> type, what is signed, etc? These facts aren't needed to implement
> call_traits.
>

call_traits will pass by value builtin types.  compressed_pair will also be
dependant on type_traits.  The purpose of type_traits is to serve as a
single collection for all specializations necessary to support these and
other future classes.  Why define what a builtin type is twice?

> My point of view is that traits are a good idea, but not the solution to
> everything. Furthermore, while I understand and agree with the drive to
> produce a general solution rather than having hundreds of individual
traits
> types, nevertheless it is wrong to generalise beyond the point of
> diminishing returns. As far as I can tell, we're well beyond that point by
> now - traits like is_builtin_integer are being used only to implement
other
> traits, which seems like a bad thing.
>
> Just my 2p worth.
>

Your remarks are welcome.  However, I disagree.  With this release of
type_traits, I have tried to break everything down into the smallest
fundamental unit.  This is because we don't know what type of future classes
may be dependant on type_traits (N-bit integers, rational numbers,
arbitrary-precision integer/arithmetic) or what type traits they may need.
For this reason, I have attempted here to define, once and for all, all
truly fundamental type traits.

        -Steve

P.S.  As to the implementation details, either structs or enums, I really
don't care as long as the interface and meanings of categories are
well-defined.