"Robert Ramey" <ramey@rrsd.com> 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