Re: [boost] suggestion on assertion macros

Subject: Re: [boost] suggestion on assertion macros
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2010-03-13 05:43:59

> there were a discussion recentrly about verifying arguments of
> assertion macros while checks are turned off

> i've got an idea of how to check the argument(s) and guarantee zero
> code size and runtime overhead

Hi,
This is a good addition to assertions, but once we decide that we are
improving assertions, there is much more that needs an improvement.
Most of them are listed in the thread on Contract++ library (proposed
for Boost) that you are already referring to. But let me list the
potential improvements here.

1. If the expression in assertion throws an exxception, this should
also be considered an assertion failure. Otherwise evaluating or not
evaluating an assertion may render different program behavior. You can
implement that by wrapping the expression with a try-catch block; but
then assertion is a statement rather than an expression. Personally I
think it is even better that an assert in a statement and it cannot be
a subexpression of a bigger expression, but it no longer complies to
assertion interface.  Lambdas have the capability of changing
statements into expressions, but we do not have them yet.

2. Be able to disable some assertions, but not all, e.g. I want the
following assert in my code never to execute:
  assert<low_level>( is_sorted( v.begin(), v.end() ) );
  find_logarithmic( v.begin(), v.end(), val );

Simply because it may be too slow even in debug.

3. I may want to disable even syntax checking in order for my
compilation to run faster. I guess we should also consider user that
prefer slower applications that compile faster

4. Make sure that the expression does not access any global variables.
Well, we shouldn't really forbid that but give it as an option for the
programmers that like "functional style" programming. I don't know how
to do that now, but with lambdas, I believe it is posible with empty
capture lists.

5. At least try to limit the possibility of the expression having any
side effect. Contract++ ttries to do it by enforcing the const
correctness of some inputs.

Perhaps, even the old assert is left alone and some super-assert like
the one from Concept++ should be incorporated into Boost and be the
preferred way of veryfing user assumptions.

Regards,
&rzej