Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2004-01-12 01:39:19


>
>
> Right. Looks very neat though, with this simple walkthrough. Any
> chance of stripping it to bare-bones, or doing a "portable asm int 3"?
> Tell you what I'd like to do: An assert() or ENSURE() that,
>
> A) Stops at the line of the assertion
in the current it's pretty hard, but it's doable.
I intend to extend it to work like this in the future.
Unfortunately don't have the time right now :(

> B) Allows debugging from that point
smart_assert can do it.
> C) *SUPER* light-weight; maybe a handful of assembly instructions overhead.
>
> The reason for the last requirement is that "I have a dream", where
> programming and debugging in C++ becomes like doing it in Eiffel, where
> you traditionally,
>
> 1) Design a few class interfaces, like in C++, functions and members.
> 2) *Write the invariants code.*
> 3) *Stuff the functions with preconditions and postconditions*
> 4) Compile (phase 1) just to debug contract correctness.
> 5) Define the functions
> 6) Compile the functions
> 7) Test/Debug
I don't understand why super light-weight.
You can use the code from Andrei & my article on CUJ (search for
"Enhancing Assertions") - that's as light-weight as I could get.

But if you do this, you lose a *LOT* of flexibility.

P.S. sorry for the "raw" documentation for SMART_ASSERT ;)

As a side-note, I've put EVERY possible effort to make it as
light-weight as possible in terms of executable code size as well.

>
> And where in step 3 you try to be absolutely thorough about requirements
> and assurances for each function. So, say, on average, you might have 3
> or 4 lines of preconditions, and say, 2 lines of posconditions, for each
> function. So, I don't see this happening with a standard assert, where
> you might have a whole page of assembly code overhead. So, it should be

Why do you worry so much about the assembly code overhead?
In release mode, it's very light weight. If you could actually
take a look at how SMART_ASSERT is implemented behind the scenes, you'll
see that any time-costly code is executed ONLY if the assertion fails.

If an error occurs, do you want your program to crash efficiently, or
continue/allow you to see what happened, possibly a little less efficient?

Best,
John


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk