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