Date: 2001-04-13 11:22:57
I've uploaded two files to an assert folder on the files section.
Don't expect the code provided there to be of much use yet, other
than being a starting point for discussion (including whether or not
such a library should be included in Boost). The design follows DbC
as described in OOSC2 by Bertrand Meyers and thus is similar to
assertions in Eiffel. Do NOT expect full DbC support. I'm not sure
that full DbC would be possible with C++ and know that it won't be
possible with out language support and/or a smart pre-processor.
What's provided is very minimalist, but will cover most needs for
error handling and debugging.
The implementation is also Win32 specific at the moment. I won't
even begin to attempt to make it other wise until after several
decisions are made. If you want to test the idea on other platforms
you'll have to change the implementation of boost::assertion_handler
for your platform right now.
Configurable assertion handling is currently not included. I can
think of only two ways to handle this, both of which have major
1) Provide a boost::set_assertion_handler() using a callback
mechanism. The problem with this is that it's a runtime policy. I'm
not sure that it makes sense to dynamically change this policy.
Further, as a runtime policy there's no way to insure a given policy
will be used by global objects (static initialization issues).
There's also MT issues that will complicate implementation. However,
this is the policy used by set_new_handler(), which has the same
issues, so it may still be deemed the proper solution.
2) Require applications to implement boost::assertion_handler(),
much as they need to implement main(). In many ways this is the best
solution, however it's intrusive on the user. If Boost.Threads used
Boost.Assertions internally the user may not realize this until
compile time when a link error will occur. If the user isn't
familiar with Boost.Assertions this link error may confuse the user.
Beyond this there's also the problem of ODR violations, which has a
greater chance of occuring than with standard assert() since there
are 5 levels of debug support instead of just 2. There's probably
other problems that I've not thought of as well, but at the very
least these need to be addressed.
Thoughts, concerns, criticisms, flames? ;)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk