Subject: Re: [boost] [assert] Assert library? - Was: [regression] Where's boost/assert.hpp ??
From: Peter Dimov (lists_at_[hidden])
Date: 2014-02-24 10:56:21
Mathias Gaunard wrote:
> They're useful if you want to write unit tests that checks that your
> functions do indeed emit an assert in a situation that is invalid.
Asserting that something should assert, how very Lakos. The function
checking its own contract is itself part of a contract.
> The main difference with Boost.Assert is that the interface allows to
> change the handler at runtime.
I'm of two minds about that feature.
Either way, it's not hard to write boost::assertion_failed that calls a
violation handler, so this is certainly implementable on top of the current
Boost.Assert. But providing a sensible - consistent, you'd say - interface
to both the old functionality and the new one (if it's added) might prove a
Originally BOOST_ASSERT was motivated by the fact that many Boost libraries
used 'assert', which generally did not offer enough control for users (of
said Boost libraries - not of BOOST_ASSERT which didn't exist yet). And it
being 'assert' by default was intended to make a search and replace of
assert with BOOST_ASSERT a risk-free procedure.
But then people started wanting more, and sometimes less. The standard
'assert', say, brings up a dialog box, and we want just simple std::cerr
output. But with a message. And sometimes we actually want std::cout output.
Or stdout, when iostreams are not available. And so on.
The idea was that everyone who wants something not-'assert' was free to
write a custom handler, but that's not how it panned out.
One way forward would probably be to just cut all ties with the standard
assert macro and go our own way. Not sure how many people this would upset.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk