[boost] Re: Exception safety guarantie

From: David B. Held (dheld_at_[hidden])
Date: 2004-07-19 18:45:36

David Abrahams wrote:
> [...]
> You have to make a distinction between layers of a system or you
> couldn't give sensible guarantees for anything.  Your policy_ptr can
> never call operator new if it's been replaced and the whole program
> has an invariant that it is never called more than some fixed number
> of times.  But of course your policy_ptr can't know anything about the
> whole program invariants, so it can make guarantees at its level of
> influence and knowledge.
> [...]

And yet, the question is how much of a library's implementation should
be exposed/documented so that the user knows what they are affecting
when they make globally intrusive changes?  I'm not suggesting that a
library should be responsible for things outside of its control.  I'm
saying that we have an issue of unavoidable coupling between the
facilities a library uses and facilities that a user can customize,
and the question becomes how much a library should expose that coupling
to make users aware of the effects of customization.  To pick an 
example, I sometimes see people complaining about whether or not some
library uses standard allocators or not.  In practice, one can customize
allocation behavior by replacing the global operator new.  But this is 
an intrusive customization which gives no guarantees to the user.  For 
all the user knows, some implementations of a given library do not call 
operator new at all, but rather use an internal allocator with placement 
new.  Should those facts be exposed to the user or not?  The initial 
uses of a library would suggest not.  You are arguing that as little 
detail as possible should be specified for a library.  There is 
certainly merit in keeping things as simple as possible and not 
over-constraining implementors.  But I'm saying that people can, will, 
and are customizing anyway, sometimes in ways not initially expected by 
the authors of a given library.  So I don't see the issue of how much 
detail to expose as an open-and-shut case.  It seems to me that the 
progression is towards customization; and that means exposing more 
implementation policies and details, so that when a user does customize
something not originally anticipated by a library author, at least the 
user knows what to expect.  And if a library is documented to be 
implemented in a certain way, then the user even gets some guarantees 
they otherwise would not get if the implementation were completely
undocumented.

Dave