Boost logo

Boost :

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at