On Sun, 16 Feb 2003 01:14:17 +0100, David Abrahams wrote: > Daniel Frey <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
