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

From: Daniel Frey (d.frey_at_[hidden])
Date: 2003-02-16 17:23:30

On Sun, 16 Feb 2003 22:52:52 +0100, David Abrahams wrote:

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

No. I think it was is_enum and I now have a patch for it, see my other
post. So, yes, I took the wrong approach when you want to see the
improvement is terms of fixed regressions. It's just that the current
implementation of the type-traits is damn hard to understand. Note that
the is_enum-patch also fixes the warning for is_class.

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

My language was (again) choosen bad, sorry. I think we *are* 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.

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.
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?). But my tests showed that even noncopyable classes were
correctly detected. So, is it desirable to have a conforming is_class
implementation for as many compilers as possible or don't we need it. I
don't really understand what is the current status.

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

I haven't meant it in any negative way. See it in the context of Genny's
post. It's just that someone (the "authorities") have to make decisions
and I'm fine with this. Although I have CVS write access, I will not just
change stuff without the OK from someone who can give an OK.

Regards, Daniel