Greg Herlihy wrote:
forced upon the programmer. The entire rationale for adding
design-by-contract support to C++ is to assist the programmer in
writing a coherent set of interfaces for an implementation - and the
goal is not find as many faults - whether irrelevant or not - with the
programmer's work as possible.
Right. There are two cases
1. The call out of the object is to be viewed as subsumed into the
implementation of the object.
2. The call out of the object is to be viewed as a temporary exit from
the object.
In case 1, re-entry to the object via a public method is an error. In
case 2,
it is not.
The proposal does not provide a means for distinguishing between the two
cases.
This is an important distinction, and one that is a frequent source of
trouble
in tightly interlinked object systems such as GUI libraries. Many
programmers
don't even understand this distinction, and it's not typically documented
in interface documents. This typically leads to wierd crashes in GUI
libraries when some unusual sequence of events results into a callback into
an object in flux. (I've seen this problem in four different
major GUI libraries. This is not an obscure situation.)
Since knowing which case applies for an object is part of that object's
external interface, a design by contract system should address this.
It's getting very abstract and hard to follow. Could you examplify these
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]