Daniel Frey <[EMAIL PROTECTED]> writes: >> That's me. I think the problem is that otherwise is_convertible gets >> instantiated on the type, and at the time the comment was written we >> couldn't instantiate is_convertible on noncopyable types because it >> required an accessible copy ctor. I think we have a new version of >> is_convertible which doesn't require that, so the test may be obsolete. > > *That* explains a lot to me. We should then fix this comment
First we'd better be sure that is_convertible actually works for noncopyable types on all compilers. > and the stuff that depends on it. If I would have known that before, > I think it would have been much easier for me to accept that > is_class's workaround is not something broken in any way, it's just > slower, depends on more parts and is hard to understand. I really don't see how my comment could have led you to believe that is_class was broken. > 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. > OK, to sum it up: We have two implementation that work. The "real" > detection is preferable for reasons of speed, readablility and > dependencies. The other version is good because all compilers eat it. > What would be an improvement in this case? I don't think that it makes > sense to add more and more #ifdef's just for the sake of > compile-speed. Others (especially those using older EDGs) may disagree with you. > Anyone who wants to work with the code should be able to understand > all implementations, thus I think it's only worth to make more > compiler accept the "real" implementation if we can manage to merge > it with the current implementation - two implementations is enough. Not sure what you're proposing to do exactly, but it sounds pretty much OK to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
