|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-11-27 13:24:45
"Robert Ramey" <ramey_at_[hidden]> writes:
> Here is the key point. I'm not really concerned about specifically
> about save_array.
>
> The save_array optimization is one example of any number
> of enhancements and/or extentions that people might want to
> make. But it is not the only example. We can't go mixing
> every great idea into the core library without running into
> an intractible scalabilty problem.
To me at least, it is very clear that you hold that view, and it has
been clear for a long time. That's why I'd like to have a different
discussion with you, mentioned in several foregoing messages:
If Robert insists [on a non-intrusive design], he is also buying
into a situation where this function in the add-on library has to be
used by every serialization function that _might_ be used in a
performance-critical context, and every archive choice made in what
_might_ be a performance-critical context must come from the add-on
library, if an appropriate archive exists there (I am thinking e.g.,
of binary archives that would be present in the add-on library while
text-based archives probably would not). That's what I want him to
think about.
If he understands what that means and prefers to avoid intrusion on
the library design anyway, Matthias and I are willing to accept that
and never bring it up again. After three years of hammering on this
one point I can't blame Robert for being tired, and I have no reason
to believe new arguments are likely to change his mind about it.
This really should be a very short discussion, after which you'll have
me and Matthias completely out of your hair on this topic. There
should be no need for long and time-consuming posts like the one I'm
replying to here. Can't we do that? Afterward we could all relax and
enjoy the holidays. :)
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk