Daniel Frey <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost