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 challenge. 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.