From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-04-27 21:55:18
"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message
> > Can you show me a better example? This is not a challenge. Really,
> > if this ENFORCE idea is a useful one I want to understand it.
> I extensively using assert-like production time enforcements to validate
> user input/order of actions. I like the idea presented in article. Though
> am curently using a little bit more C like solution:
> MY_ASSERT_MSG( condition, ("Message", arg1,arg2,...) )
> Number of arguments is arbitrary. For example:
> MY_ASSERT_MSG( m_value > 0 || m_compression_style == SIGNED_LONG,
> ("Couldn't pack value %d using
> style %d", m_value, m_compression_style) );
> Anyway, I think the solution presented is article is neat. And I like to
> some of these advanced assert/enforce solutions presented for boost.
> are you going to submit?
Thanks for the kind words. I plan on enhancing things so that people can
specify the exception type to be thrown. Something like:
transmogrify an object twice!");
ENFORCE<MyException>(obj.IsTransmogrified())("Could NOT transmogrify!");
The code does the obvious tests and throws that one would expect.
This feature was on my must-have list, but somehow it got lost in the
continuous effort of providing maximum programmer confort and maximum
information. (This particular feature conflicts for nonobvious reasons with
two others (1) have ENFORCE be an expression and (2) have ENFORCE store the
textual value of the expression being tested.)
So I expect a much more combed version of ENFORCE to be available with my
next article. However, I believe time considerations would prevent me from
writing the documentation and formal submission, but I'd sure be glad to
Again, Petru and I have had a very positive experience with ENFORCE. Without
bringing anything really unheard of, this little abstraction does reduce
clumsiness in error condition testing a great deal, both when writing and
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk