On Sun, 16 Feb 2003 03:12:13 +0100, Daniel Frey <[EMAIL PROTECTED]> wrote:
>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... Well, I have not been following this thread closely, so my apologies if I'm taking this comment out of context, however having felt more-or-less the same about type_traits I think it is right to back up Daniel in his opinion. The few times I've looked at it, the documentation was more an obstacle than a help; the easiest way to understand the purpose was to look at the code. One of the issues is terminology. For instance what does it mean: ::boost::is_union<T>::value Evaluates to true only if T is of union type. Currently requires some kind of compiler support, ->> otherwise unions are identified as classes. <<-- ? First of all, unions *are* classes to the standard (Well, I think this is just a terminology mistake. However the standard terminology is a reference for a C++ programmer, so if the docs adopt a different convention they should say so). Secondly, the sentence above is in the description of is_union<>, not is_class<>, and it's rather is_class that detects unions; and not "otherwise": it detects unions anyway! :-) As to the point of providing an implementation that "just works", I totally disagree. And I don't think this is the (stated) intent, otherwise I wouldn't use boost at all, and probably wouldn't even be subscribed to the list (if not to keep informed about what is going to be put in the standard). More generally, cleaning up implementations is IMHO a "must do" at this point of the boost evolution. Rather than worrying about ordinary releases, I think we should have the library undergoing a global review, focused on eliminating the noise that have been accumulating over the years, and the existence of ad hoc solutions in each library for things that could be factored out in an autonomous component (e.g. is_signed and related stuff in numeric_traits). Also, I hate the enormous degree of coupling of most type_traits components: let's say I include boost/type_traits/is_integral, which should be the most simple thing in the world to implement. Well, under the appearance of an innocent: #include "boost/type_traits/detail/bool_trait_def.hpp" I end up including: - template_arity_spec.hpp - bool_c.hpp and - lambda_support.hpp" (!!!) And lambda_support, in turn, includes so much preprocessor stuff that I think it is more than what I would have in the whole application hadn't I included is_integral. So why should I use it? After all I can write the same in portable C++. And, by portable I mean effectively portable even to broken compilers (the ones I use, of course). As to your impression, I know the feeling. BTW, I think that's partly due to a couple of reasons: first of all people tend to reply for disagreement more easily than for support, and that's in part logical because otherwise we would have a lot of replies which just said "yes", "yes" and "I agree" :-) Another point is that most people expect "approval" to come from one of the authoritative boost members (Beman, Dave, Peter, etc.). Speaking for myself, even if I agree with a change that you propose, I don't feel to reply with, let's say, a "yes, let's do it", because I don't feel to have the weight to make such an assertion here. And I imagine this is the way others think about the matter as well. What to say? Just that I expect someone to be hurt by these words and reply with a biting tone. Probably something along the lines of: if you have something better then propose it! I know, in any case, c'est la vie... :-) Genny. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
