[boost] Re: Re: Re: is_class

From: Daniel Frey (d.frey_at_[hidden])
Date: 2003-02-15 21:12:13

On Sun, 16 Feb 2003 01:14:17 +0100, David Abrahams wrote:

> Daniel Frey <d.frey_at_[hidden]> writes:
> 
>> I won't try to fix any of these anymore. I neither understand the
>> documentation nor the implementation of boost's type-traits. I tried to
>> make the code better but AFAICS there is no interest in improvment.
> 
> Does anyone understand what improvement you're trying to make?

I have the impression that the type-traits can and should be improved. I
don't have a complete solution for everything at once and I prefer
evolution over revolution. Thus I tried to start by suggesting a new
is_class implementation. I was disappointed to see only bashing on details
instead of a discussion of the "big picture".

The basic point was (IMHO) never answered. I tried to clean up the
implementation by providing a closed implementation of is_class for more
compilers. This should decrease the coupling of all the different parts. I
think that this is a better design than the current one. The example I
gave which I thought might show the local problem was wrong. My fault,
granted. But does it speak against cleaning up the code?

As far as I learned right now, boost is not meant to provide a clean
implementation, instead, it provides a good documentation and an
implementation that "just works". But even the documentation confused me
several times. is_scalar doesn't mention enum, is_member_function_pointer
is not a secondary type category, the mixture of utility functions and a
framework and primary type categories are implemented using secondary
type categories. Even if it works, it is IMHO still bad code. My only
chance to understand type-traits was to create my own implementation from
scratch. But maybe it's just me...

Regards, Daniel