Re: [boost] suggestion on assertion macros

Subject: Re: [boost] suggestion on assertion macros
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-03-14 22:54:09

Hello all,

I have listed a few questions below.

ASSUMPTION: Assertions should be used to document, program, and check
software specifications. (*)

On Sat, Mar 13, 2010 at 3:34 PM, Emil Dotchevski
<emildotchevski_at_[hidden]> wrote:
> Why don't we leave assertions alone? Anything you do to "improve" them
> makes them more tolerable which makes them something other than
> assertions.

All assertion "improvements" listed by Andrzej together with Contract
Programming invariants, preconditions, postconditions, and
subcontracting aim to better serve the assertion purpose (*) of
programming software specs. These improvements are taken and
elaborated from [Meyer1997], [Crowl2006] (all previous revisions of
this proposal are also relevant), and even [Stroustrup1997] (see
http://dbcpp.sourceforge.net/contract__/bibliography.html for a list
of the [xyz] references I am using in this email).

For example, [Crowl2006] shows how most of the std::vector specs can
be programmed using the Contract Programming assertion improvements.
Now, if we were to leave C-style assertions alone, without improving
them, then we would not be able to program the std::vector specs --
would we?

Furthermore:
1) Which one of these assertion "improvements" makes assertions "more
tolerable"? Why and how?
2) Tolerable to what?

On Sat, Mar 13, 2010 at 3:34 PM, Emil Dotchevski
<emildotchevski_at_[hidden]> wrote:
> Assertions should print a message and exit. OK a smack to the head
> would also be an improvement but that's about as far as I'd go. :)

Indeed, by default, the Contract Programming "improvements" discussed
above print a message and then they std::terminate() (no exit(), nor
abort(), nor throw). (None of these "improvements" smack programmers
yet and I am thankful of that because I know I will keep making coding
errors :)) .)

On Sat, Mar 13, 2010 at 5:21 PM, Mateusz Loskot <mateusz_at_[hidden]> wrote:
> Well said.
> The idea of "Be able to disable some assertions, " sounds
> especially weird. Assertions are not for purpose of logging
> and such. Categories of assertions severity make little
> sense to me.

As Andrzej explained, there is a specific use case for "disabling some
assertions" and it has to do with the computational complexity of the
assertion check.

For example, assertions can be used to program the following specs:
(a) "After vector::push_back(x), x should appear at the back of the vector".
(b) And also "after vector::push_back(x), no other vector element, but
the newly added x, has changed".
These conditions both assert software specs so they are within the
stated purpose for assertions (*).

As explained for example in [Mitchell2002] (or better yet by most AI
books), (b) uses assertions to program "frame conditions". Frame
conditions are notoriously computationally expensive to check: In this
example (a) can be checked in O(1) while the frame condition (b) will
run in O(n) (where n is the size of the vector).

Therefore, "categories of assertion severity" (or to use a better term
"assertion importance ordering" as mentioned in [Crowl2005]) could be
used to tag frame conditions with a different importance level so to
disable frame condition assertions while keeping the other assertions
for the sake of efficiency.

4) What does this "assertion importance ordering" use case have to do
with "logging and such"? (I think it has nothing to do with logging
and all to do with the computational complexity of the assertion
check...)

In my opinion:
i) The improvement suggested in this email thread to disable
compilation of the C-style assert() based on NDEBUG is relevant in the
context of selectively disabling assertion compilation and checking (I
might actually use it in my Contract++ library for the
CONTRACT_BLOCK_INVARIANT() macro).
ii) However, for an OO language like C++, this one improvement should
be considered within the broader list of assertion improvements
indicated by Andrzej and captured by Contract Programming so to more
comprehensively serve (*).

Regards,
Lorenzo