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

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-16 11:05:48

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

> But I think that #ifdefs should only be the very last option. 

Your philosophy goes against the one which says that breaking working
implementations should be the last option.  I'm sorry, library
maintainers have an obligation to their users to keep the code
working, and you can't expect that to change just because you don't
like #ifdefs.  If, as you claim, you want to improve things in small
steps, have your steps affect compilers which you know can handle them.

> It is part of the current problems as we already have too much
> #ifdefs which are confusing. I think that the use of
> BOOST_WORKAROUND will improve the situation, but I prefer to remove
> #ifdefs completely. 

I agree, when possible, and when the resulting implementation isn't so
fragile that it's impossible to touch without breaking it.  I don't
agree at all that the kind of #ifdefs you find in
boost/mpl/integral_c.hpp are confusing: they say very explicitly which
pieces of code are used for which compiler implementations.  This
might in fact be an improvement to using a single implementation which
is a house-of-cards and has no documentation about which elements are
needed to support which compilers.

> See also the discussion about a "general coding guideline" to
> "always provide a name for template parameters". 

I never saw that discussion.

> Here, the maintainer already did the right thing when he received
> the patch. I think we should aim for removing as many #ifdefs as
> possible. 

AFAIK we always do.

> Maybe we can't do that in case of the type-traits, but I would like
> to try it first before giving up and creating yet another
> implementation that is guarded by #ifdef. (Which then might no
> longer be an improvement).

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

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