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: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
