[boost] Re: is_class

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-02-16 07:28:41

On Sun, 16 Feb 2003 03:12:13 +0100, Daniel Frey <d.frey_at_[hidden]> wrote:

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

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.