From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-02-16 14:21:13
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
# define BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION
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
> 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.
-- 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: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk