[boost] Re: Invariants Library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-02 22:14:44

"Dan W." <danw_at_[hidden]> wrote in message
news:bt3rse$2dm$1_at_sea.gmane.org...
> Thorsten Ottosen wrote:
>
> > I recall that one could choose not to remove preconditions
> > from release builds.
>
> In public interfaces no, as the preconditions are in the extracted
> header, but the preconditions in private functions, and all non-public,
> implementation classes in the object code, preconditions are gone.
> Wouldn't make sense to keep them without source code to debug.

I meant from the object code. If you cannot remove debug stuff from your
object code, then you might choose not to use it.

> >>1) DBC statements should be header-file only, if there's any way to
> >>ensure this, so that they are public, available to users of a library,
> >>and may so constitute 'documentation'.
> > While this might be good for quick and dirty implementation, it would
> > totally ruin the
> > overview of a class. It will also create more re-compilation because the
DBC
>
> "..ruin the overview of a class"?! The class *IS* its contracts!

yes, but from a design perspective you really want to keep an overview of
your code, if you can. This is one of the problems with C++ and templates
today.
you either implements everything inline in the class and loose the overview
of what you're
doing or you implements everything after the class declaration and type in
sooo many
characters in the file that you get COBOL-fngers. (btw, there is a proposal
that aims to solve this).

> > code would have to be placed/maintained
> > in headers.
>
> Maybe we're talking about different parts of DBC... Okay, variant and
> invariants are not meant to be 'public DBC', and should NOT be in the
> header file.

Not the invariant? I would have said that a part of the invariant that
describes
certain relationsships between the public value returning functions would be
usefull documentation.

> Maybe I should have clarified that; sorry, my fault.  But preconditions
> and postconditions in public functions are what defines and documents
> what those public functions demand and promise, for all to see.  If they
> were non-header, it would mean that the contract could be secretly
> altered, without the consent of the class' clients.

yes, but couldn't one just extract documentation from the source file? As I
understand it,
the Eiffel headers is already an extract of the source files? No matter what
scheme, you would still
have to read the updated documentation (whether a header or something else).

br

Thorsten