Boost logo

Boost :

From: Samuel Krempp (krempp_at_[hidden])
Date: 2003-04-29 11:02:48

Le sam 26/04/2003 à 21:46, Andrei Alexandrescu a écrit :

> > I browsed the article (I confess to not having read everything, so
> > please correct any misapprehensions). My sense is that the technique
> > is oriented towards detecting programmer errors and responding via an
> > exception.
> No.

it's true your examples, like
Enforce(cout) << Enforce(MakeWidget())->ToString();

emphasize errors dependant on environment rather than algorithm errors.

I feel attracted by the set of nice features packed in enforce.

But the same facility would be very useful for programmer errors too, as
a way to state algorithm invariants with minimal overhead and
comfortable formatting abilities, like a nice, extended, assert.
BTW this is what the original thread was about, with John Torjo's
(Of course, when a program fails an assertion, a core has all the
information you can dream of. But I still like to get a good error
message with the values of the interesting variables even before
launching the debugger, as it is often enough to understand what is
wrong. So I'm as intersted as John in a good way to enhance the basic
assert macro)

In the context of a boost proposal of this Enforce thing, I think it
would be good to simply provide 2 different macro names to address those
2 slightly distinct needs, e.g. ENFORCE and INVARIANT. (or THROWIF and
ABORTIF, or whatever sounds self-explaining)

of course both facilities would be very similar, but the distinguished
names would stress the 2 different types of error checkings, and that
seems to be an important point.

In fac, with a suitable defintion of a

struct DefaultAborter;

inside which a throw(..) function prints a message and aborts, INVARIANT
could simply be defined by :

#define INVARIANT(exp) \
    *MakeEnforcer<DefaultPredicate, DefaultAborter>(\
        (exp), "Expression '" #exp "' failed in '" \
        __FILE__ "', line: " STRINGIZE(__LINE__))

now we get an alternative to John Torjo's smart_assert :

> assert( (i < j) || (i == 0) || (j == 1) ); would change into
> SMART_ASSERT( (v_(i) < v_(j)) || (i == 0) || (j == 1) );

INVARIANT( (i < j) || (i == 0) || (j == 1)) (i) (j) ;

looks as nice, and feels more comfortable to me.
(and maybe has less overhead than SMART_ASSERT's v_(..) mechanism,
though I didnt went into it)

Note, to make this ".. (i) (j)" work, the operator() in Andrei's class
would have to print spaces automatically.

I'd like that to be provided inside boost..



Boost list run by bdawes at, gregod at, cpdaniel at, john at