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

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-16 12:58:13

Daniel Frey <daniel.frey_at_[hidden]> writes:

> Often, granted. But the above patch (the link I gave) shows, that we
> also have already evidence of #ifdefs that should be removed.

Actually, there is some argument for keeping the #ifdef there.  HP is
currently working on fixing their compiler and using our regression
tests to do it.  With the #ifdef and the appropriate define to turn
off workarounds, they will detect the bug.  Without it, they won't.

I really prefer the solution that uses a single implementation as you
do, but I'm just trying to point out that determining which approach
is superior isn't as cut-and-dried as you're making it out to be.

>> I think everyone is happy to have improvements as long as they work.
>> The bottom line is, if you want your "improvements" to be accepted,
>> you have to invest the energy to make sure you're not going to break
>> things for existing clients of the libraries. It's unrealistic and
>> unfair to expect volunteer library maintainers to take your code and
>> figure out how to make it work correctly, especially without ifdefs.
>> Boost code lives in the real world, not in an idealized one where
>> everything can be done "on principle."
>
> I tried my best to create an implementation that works in the real
> world. I tested it for the GCC and the Intel compiler, which is all
> I can do. I hoped for a discussion which might lead to an
> implementation that works for a great variety of compilers but it is
> not going to happen AFAICS.

Well maybe we should start over.  The way this whole thing started it
sounded like a lot of judgemental complaining about the current state
of the library without any willingness to bend your principles enough
to do something that was actually practical.  Let me also point out,
just to be clear, that handling "a great variety of compilers" is not
enough.  Any solution we have has to work for all the currently
supported compilers.

> I don't see why it is unrealistic or unfair to think that some
> boosters might be interested to work on it, though. 

It isn't unfair to expect that some boosters might be interested in
working on the problem.  It's unfair to expect that any particular
booster will have the time and inclination to pursue a reorganization
of working code for no gain in functionality, especially if it looks
to them like you'd be willing to sacrifice a working implementation on
some supported platforms in order to satisfy some aesthetic ideal.

Personally, I don't believe there's any way your proposed is_class
implementation can be bent so that it will work on many compilers.
I've tried it.  How do you envision the process of eliminating #ifdefs
in that implementation is going to work if you're not going to run the
tests on the other compilers and massage the code yourself?  Pretty
quickly whoever is testing on vc6 is going to lose patience with your
goal of eliminating all #ifdefs, aren't they?

> I don't expect my "improvements" to be the holy-grail that is
> applied immediatly - it was just meant to start a discussion about
> it. If you re-read the first message of this thread, I think you can
> see that.

I don't know; it looks to me like the beginning of the thread is
mostly about (incorrect?) claims that  the current implementation is
broken.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com