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

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-16 16:52:52

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

> David Abrahams wrote:
>> 
>> 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.
>
> Let's look at the current status:
>
> # if (defined(__MWERKS__) && __MWERKS__ >= 0x3000) || BOOST_MSVC > 1301
> || defined(BOOST_NO_COMPILER_CONFIG)
> #   define BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION
> #endif

Ick!

> We don't need to create an implementation that works for *all*
> compilers. We could just try to find an implementation that works
> for *more* compilers than today.

Are you saying that the current implementation of is_class is broken
for some compiler?

>> > 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
>
> I think that we have some fundamental disagreement about this "no gain
> in functionality"-point. 

*Is* there a gain in functionality in your proposal?  I'm still
unclear about that.

> I don't consider it an aestetic ideal but a real helper in the long
> term

Cleaner code is always a helper in the long term, but that's different
from a gain in functionality.

> although I cannot show a direct improvement immediately. It's just
> what experience teached me, nothing I can prove.

I wouldn't argue with you about that.

>> to them like you'd be willing to sacrifice a working implementation on
>> some supported platforms in order to satisfy some aesthetic ideal.
>
> To hopefully make that point clear: I don't want to break anything and I
> don't want to sacrifice the implementation or compilers or platforms,
> etc. We have a "real" implementation and a workaround. If we can manage
> to create a better "real" implementation which works for more compilers
> today, this would IMHO be an improvement. 

I agree.  You'd have to be willing to use #ifdefs, though.

> But the discussion is becoming more and more pointless

Just when I thought we were getting somewhere!

> it seems that I have a different view about software development
> than the authorities here.

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.

Well, let me be clear about this at least: at no point in this
conversation was I intending to post "as an authority."

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