Re: [boost] [assert] Assert library? - Was: [regression] Where's boost/assert.hpp ??

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