Re: [boost] Re: Re: RE: Re: Re: Re: is_class

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-02-17 04:02:58

David Abrahams wrote:
> 
> >> But I was under the impression that is_class's workaround must be
> >> broken in some way - although I couldn't see it. (Yes, I shouldn't
> >> have claimed what is broken from just reading code - I should have
> >> at least tried it out). I think I should not assume such things in
> >> the future but ask instead...
> >
> > I guess so, or think harder about the comments you /do/ read.
> 
> Sorry, all of this sounds a lot too judgemental or something. Please
> accept my apologies.  I guess I'm just confused about how my comment
> led you astray.

No need to apologize. I never meant to say it was your fault, the
comment was just the last piece in the puzzle that I needed to
understand how things went wrong. Let me try to explain it from the
beginning.

I started to implement my own type-traits to see if I can do it and to
learn something. While doing so, my design lead me to some dependencies:
is_enum needed is_class, is_scalar needed is_enum. When I had a working
version, I started to look at the boost implementation to see if I have
made something wrong and if any of the two (my version and boost) can be
improved. My regression tests showed me that there were some warnings
for boost's is_class and is_enum. Given the above dependencies of my own
implementation, I looked at boost::is_class first. Here I found a
situation where we have a
"BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION" and a workaround. The
workaround used boost::is_scalar, which I missed. is_scalar's
documentation doesn't mentioned is_enum, although it was in the code.
But anyway, enums weren't detected as classes. And boost::is_enum had a
comment which seemed to say that it needs a working is_class
implementation in order to work correctly. Thus, I concluded (wrongly)
that the point to start should be to "fix" boost::is_class if possible.
That was the reason for the start of this thread.

Now, who's fault is it? Certainly it's just my fault, as I was too
impatient. I apologize and take the responibility for the heat of the
discussion. The comment from you was not wrong at the time it was
written and was meant to help people looking at the code. Later, it
turned into a false hint, but I guess these things just happen in any
sufficiently complex system (and boost definitly qualifies for this :).

The good thing is, that we now can fix some of the stuff. is_enum's
documentation is already fixed, is_enum's implementation can be fixed by
the patch I posted or - if dependencies worry you (or John or others) -
the patch can be modified to be guarded by #ifdef's (yes, I really said
that) in order to reduce dependencies for other compilers. The comment
and thus the whole "#if
defined(BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION)"-part in
is_enum that is currently in there could be removed and thus is_enum no
longer depends on is_class. And finally, if I got you right, it might
also be useful to use my is_class-version to add it even if we have 3
versions in is_class then. I guess that the "older EDG-versions" you
refer to are really slow when having to instantiate all the dependecies
of is_class's workaround, right? Still a lot of work to do, I guess. And
as a last thing to clean up, is_member_function_pointer could IMHO be
moved to the primary type category in the documentation or - even better
- we should drop the distinction into primary and secondary type
categories as it IMHO buys us nothing - instead it again lead me to the
wrong direction which is why I never expected is_class to depend on
is_scalar. And to let there be no doubt: These are all just proposed
changes/fixes, not the holy grail. Discuss them as needed as I might
have missed something :))

Lessons to learn for me:

a) I shall not be so impatient.

b) I shall not make claims so easily, I shall not base them solely on
what I read and think.

c) I shall not trust documentation or comments. I should better try it
out and - in case of doubt - read the code without comments.

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de