Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-27 12:27:54


"Peter Dimov" <pdimov_at_[hidden]> writes:

> Even if it did work, I don't see in which circumstances a class author would
> like to _not_ take advantage of the save_array enhancement. Ideally, he
> should just call save_array in save, without restricting it to a specific
> set of archives. I don't see what you gain by denying him this opportunity -
> assuming that it can be provided without negative consequences for the
> current code base or existing archive formats.

While I agree with this argument, it's been made more times than I can
count, to no avail. I don't see why it should succeed this time, even
coming from you. It seems to me it can only make Robert feel more
beleaguered.

I'd really like to remove the pressure from Robert to do what the rest
of us think is best so that he can consider the following (quoting
myself):

  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.

Robert, I am happy to elaborate on the first paragraph if you still
don't understand what I'm talking about.

-- 
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