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

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-16 19:24:36

Daniel Frey <d.frey_at_[hidden]> 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