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 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. > > 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. I don't consider it an aestetic ideal but a real helper in the long term, although I cannot show a direct improvement immediately. It's just what experience teached me, nothing I can prove. > 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. But the discussion is becoming more and more pointless, it seems that I have a different view about software development than the authorities here. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost