From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-05-01 02:58:21
| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]]On Behalf Of Andrei Alexandrescu
| Sent: Saturday, April 26, 2003 2:49 AM
| To: boost_at_[hidden]
| Subject: [boost] ENFORCE (was: better assertion technique)
| By the way, I believe what would be more interesting for Boost is the
| recent article (http://www.cuj.com/experts/2106/alexandr.htm), written by
| Petru Marginean and myself.
| We have good experience in reducing source code size by using enforcements.
| There are a number of interesting techniques used out there, and I believe
| ENFORCE would be quite useful as a Boost library.
Initial experiments (MSVC 7.0) with ENFORCE leave me rather impressed with the
flexible and painless way it makes it easy to provide informative and helpful
messages about problems occuring at __RUN__ time - as opposed to better
'asserting' at compile time, thought it isn't bad at that either. I feel there
is some virtue in separating assert checks which are programmers internal checks
from what may go wrong at run time for reasons beyond the control of the
programmer of a particular module.
I haven't looked at the cost, but AA promises it is modest for the benefits.
To sell better, it needs lots and lots more working examples of the various ways
in which ENFORCEMENT may be used, as outlined in the CUJ article. I'd like an
expanded version on the Boost site.
As a consumer, I can't think of many programs which have never bombed. But I
have never been able to provide any clues to the authors who one imagines in
blissful ignorance of the seriously bad things said about them. A way to tell
them would help them, and it would certainly lower my blood pressure. emailing
an error log would be one simple mechanism. I suspect ENFORCE would be a cheap
way of preparing this, and even help sending it?
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk