[boost] Re: Type Traits, Take Two

From: Moore, Paul (Paul.Moore_at_[hidden])
Date: 2000-01-10 08:11:42

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

[BTW, I find this quoting style very hard to read - I keep losing the end of
the quote...]

> 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").

> Assertion checking:  If T is not a built-in integral type 
> then portability assumptions may break down.

I'd tend to say document the requirements, and leave the conforming to the
user. I can't think of anything which would break based on a built-in
integer vs other type distinction. I suspect you are glossing over your real
requirements. Do you have a real case where code works for all built-in
integral types, but cannot, under any circumstances, work for a user-defined
type? (OK, "the user should specialise" - but how? Say his type is a
built-in integer when it isn't?)

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

> Smart adaption:  If a method expecting a function object gets passed a
> function pointer instead, we can automatically adjust (using is_pointer).

OK. If this is a useful thing to do (is there a concrete example, preferably
one which is not simply a borderline optimisation?) then I can accept the
usefulness of something like is_pointer. But again, it's a specific trait
that's needed - is_function_pointer_rather_than_object. STL has Adaptable
Function and Function (or some such name) concepts, which embody a sort of
"object only vs object or function pointer" distinction. They got by without
a traits type.

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.

Paul.