[Insight-developers] My Dashboard Compile Errors and assert()'s

[Steve M. Robbins]

On Sun, Aug 10, 2008 at 02:08:33PM -0400, Bill Lorensen wrote:

> Question to itk developers: Should we allow (encourage) assert()'s in
> itk? There are 205 assert()'s in itk Code/. Of these, 194 are in
> Review. That means 11 are in released itk code.

Personally, I'm drawn to design-by-contract which isn't yet possible
in C++, though it has been proposed [1].  Lacking language support, a
reasonable compromise is inserting ad-hoc tests of preconditions and
postconditions.

As Stephen A points out, the trouble is that different people have
different needs when a condition is violated.  Sometimes, the
behaviour of assert is what you want, i.e. to drop a core dump file or
drop you into a debugger.  

Sometimes, however, it is *not* what you want.  Furthermore, the
author of ITK code can't know what the application writer wants, so
I'm with Stephen: assert() is bad.


One alternative that I have seen used in CGAL [2] allows:
  (a) checks to be compiled in or not, and
  (b) failure behaviour customized at run-time.

The second feature allows the application writer to select
either "abort()" or "throw", among others.  So you have the
best of both worlds.  Or your choice of worlds, at least.  :-)

Crucially, the flag to enable checks to be included is *NOT* NDEBUG.
It's obvious when you think of it that precondition checking is an
orthogonal concern to whether the code is "debug" or "release".

CGAL goes much further, however.  You can individually turn off
preconditions, postconditions, assertions, and warnings globally.  You
can also turn them on or off for certain modules.  Further, some
checks are disabled except in certain circumstances:

    Not all checks are on by default. All four types of checks can be
    marked as expensive or exactness checks (or both). These checks
    need to be turned on explicitly by supplying one or both of the
    compile time switches CGAL_KERNEL_CHECK_EXPENSIVE and
    CGAL_KERNEL_CHECK_EXACTNESS.

    Expensive checks are, as the word says, checks that take a
    considerable time to compute. Considerable is an imprecise
    phrase. Checks that add less than 10 percent to the execution time
    of the routine they are in are not expensive. Checks that can
    double the execution time are. Somewhere in between lies the
    border line. Checks that increase the asymptotic running time of
    an algorithm are always considered expensive. Exactness checks are
    checks that rely on exact arithmetic. For example, if the
    intersection of two lines is computed, the postcondition of this
    routine may state that the intersection point lies on both
    lines. However, if the computation is done with doubles as number
    type, this may not be the case, due to round off errors. So,
    exactness checks should only be turned on if the computation is
    done with some exact number type.
    [2]

This could address Gaëtan's concern about running time of the checks.


If you want to explore more sophisticated approaches, design by
contract has come up on the Boost list, with at least one proposal by
Yariv Tal [3].  This proposal has a nifty feature:

    Unlike many other such libraries it allows for defining all
    condition types at the begining of the method, instead of making
    you define the "post" checks just before method exit (which
    usually constrains you to a single-point-of-method-exit design).

Unfortunately, the post just has examples, but no actual library code.

Jarl Lindrud did provide code for a similar effort [4] including a
POSTCONDITION() macro that can be declared at the top of a function
and evaluated at function exit.  Note that the technique used for this
by both Yariv and Jarl has a compile time impact.  I haven't studied
Jarl's library, but maybe it could be useful to ITK.  Some food for
thought, at least.


Cheers,
-Steve


[1] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1962.html
[2] http://www.cgal.org/Manual/3.3/doc_html/cgal_manual/Introduction/Chapter_main.html
[3] http://lists.boost.org/Archives/boost/2005/04/84332.php
[4] http://www.codeproject.com/KB/cpp/DesignByContract.aspx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20080811/4a6c27cb/attachment.pgp>