Re: Contract checking in Ada

["Randy Brukardt" <randy@rrsoftware.com>]

"Tapio Kelloniemi" <spam17@thack.org> wrote in message
news:Oe73e.6358$qc.2422@reader1.news.jippii.net...
...
> Programming by contract features are IMHO disabled (speaking in free
> software terminology) when a stable version is released, or in other
> words, when a final product goes out.

That's a horrible idea. That's like wearing a life-preserver when training
on land, and then discarding it when you go to sea!

The problem is that assertions of all stripes (like runtime checks) detect
unanticipated conditions before much damage is done. And no one antipicates
(and thus tests) every possible issue.

Yes, sometimes you have to suppress checks (and conditions), but you want to
do that only in the most performance critical parts of your application. A
feature that makes your whole application like that is a feature that will
be rarely used.

> Xconditions are certainly a huge
> performance hit, but not as much as inserting a break point at the
> beginning and end of every subprogram in a debugger and then manually
> examining parameter and result values, if program behaves oddly. All other
> run-time checks are also expensive and that is why Ada provides a way to
> disable them. Xconditions could actually speed up code that is considered
> to be stable. This is because subprograms' parameters' validity checking
> can be written as a precondition and does not need to be executed, when
> the caller knows that a bad value cannot be passed in any situation.
> For example subprograms of Ada.Strings's child packages have many checks
for
> their parameters' validity and as some of the subprograms are implemented
> (in GNAT) in terms of others, the checks are doubled.

That's also a bad idea. Indeed, we had something like that in pragma Assert
and eventually dropped it because of the objections. Again, the issue is
that you need to be checking for the unanticipated. You shouldn't be
assuming that the asserts will pass without checking.

OTOH, the compiler may be able to optimize out checks and preconditions on
calls given the preconditions on the arguments. That's fine (its the reason
for the null exclusion, for instance); but doing so by assumption, rather
than by checking, is bad news.

                     Randy.