David Abrahams wrote in message ...
>"Anders J. Munch" <andersjm@post.tele.dk> wrote in message news:8hu388
>
>> That means the invariant that appeared to be tightly linked with the
>> constructor, suddenly is not.  Indeed the C++ object 'c' may exist for
>> a long time before it can be said to contain a complex number.
>
>Though I think Herb may be stretching a bit in linking invariants to type
as
>he is trying to do, I think you have misunderstood the true meaning of the
>word "invariant". The invariant which is in the eye of the programmer may
or
>may not in fact be an invariant for the class. Surely if an object is fully
>constructed without satisfying some condition that condition can't properly
>be called an invariant of the object's class.

Informally the word 'invariant' is often used about a statement of the
programmer's intent; as for example in the sentence "it is checked at
run-time that invariants hold".  In the formal sense of the word where
the invariant is a logical property of the program, such a check would
be meaningless as it would always be true.

This is a distinction with little bearing on the discussion, though.
For a bugfree program the two will be the same.

Next expression to define is "an invariant of the object's class".  I
would like to say that any kind of invariant that rises above the
individual methods deserves that title.  However you seem to be using
the expression in a much narrower meaning, for something which I would
call "an invariant of the public interface".

An invariant of the public interface is an invariant which holds true
between invocations of public methods, including the ctor and the
dtor.  The point of my example was to demonstrate that (sound) designs
exist where an invariant of the public interface would not say
anything interesting, but where a different invariant of the object's
class can.  The invariant for Math::Complex that kicks in after the
object is assigned to is no less a class invariant because of the late
start: this is no different than that an invariant of the public
interface doesn't apply until the constructor completes.

Another example is the protected interface.  The protected interface
can and should have its own invariants, it is just as valid an
interface as the public one.  Remember that before assigning special
status to the public interface.  The programmer may define more
interfaces, say a private interface which encapsulates instance
variables.  Such an interface would have its own invariants, even
though the language doesn't help enforce them.

The language support for the public interface makes it a convenient
borderline at which to maintain a set of invariants.  But that is all
that is special for the public interface.  The programmer can define
other borderlines and, through a conscious effort, uphold invariants
at those borderlines.

- Anders

--
Anders Munch, andersjm@post.tele.dk
Still confused but at a higher level.


---
[ 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. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]