Boost logo

Boost :

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,
> > 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
> > 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
> > 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
> 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
> 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.


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

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