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