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

From: Daniel Frey (d.frey_at_[hidden])
Date: 2003-02-16 19:11:14

On Sun, 16 Feb 2003 23:40:14 +0100, David Abrahams wrote:

> Daniel Frey <d.frey_at_[hidden]> writes:
> 
>>> I agree.  You'd have to be willing to use #ifdefs, though.
> 
> No reply to that?

I thought that was implicitly given. Yes, #ifdefs are needed. They are
already there. I just don't want to add more #ifdefs as needed. Or remove
them if it makes sense. I admit that it took me some time to understand
all the stuff involved. Your last message was an eye-opener for me, as
I'll explain below. From the very beginning, I had the impression that
there is something wrong with is_class/is_enum and that we should work on
it. As I wasn't able to find out the details exactly, I thought that
trying to "fix" is_class for the compilers I have might be a good idea -
in retrospective I was plain wrong. It was is_enum that caused the
warnings (also for is_class), some documentation which confused me and
the wrong comment in the implementation.

>>> Where is the fundamental disagreement?  It seems as though you're
>>> willing to use #ifdefs, since that's pretty much the only way to have
>>> a workaround implementation, and you seem to have accepted the idea
>>> that one may be neccessary. Therefore, you can easily make patches
>>> which enable a "real" implementation for compilers you can test (or
>>> reasonably assume will work -- i.e. other EDG compilers with the same
>>> __EDG_VERSION), and other people can see if they can also use your
>>> implementation on other compilers; we can keep the codebase functional
>>> and still improve its cleanliness; everyone will be happy.  I just
>>> don't get what we're arguing about.
> 
> No answer for that?

Well, given that is_class's workaround is not broken, the priority to
provide a non-workaround version is *much* lower. I no longer think it's
a useful idea, especially given the fact that it's freaking hard to make
compilers agree on what an implementation should look like. And there is
progress as I think we will fix some more docs and comments, so we don't
disagree...

>> I just had another thought: *If* the workaround has no drawbacks, why
>> don't we remove the "real" implementation? Why was it provided? Maybe
>> this is a fundamental point, too. There "should" be a drawback,
>> otherwise the workaround is already the clean one-size-fits-all code I
>> am looking for.
> 
> Unless it has more #include dependencies than it needs for a conforming
> compiler, or instantiates a lot more templates than it needs to for a
> conforming compiler and thus compiles slower, or... is just damn hard to
> understand.
>
>> The existence and some comments in the code just give me the feeling
>> that this is not the case. As an example, look at is_enum and the
>> comment from dwa (Darryl?).
> 
> 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 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. 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...

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

Regards, Daniel