On 23/02/14 15:29, Peter Dimov wrote:

Mathias Gaunard wrote:

...

Apparently people prefer having plenty of different macros which have non-obvious interactions with each other instead of a single macro that always does what's asked.

In what way do the current macros not do what's asked? What would you like to see instead?

Try to answer the following questions: - what's the difference between BOOST_DISABLE_ASSERTS and NDEBUG? - does defining BOOST_ENABLE_ASSERT_HANDLER affect whether assertions are enabled or not? - what's the difference between BOOST_ASSERT and BOOST_ASSERT_MSG The answers one would expect are: - BOOST_DISABLE_ASSERTS disables all assertions done with Boost.Assert, while NDEBUG disables all assertions done with Boost.Assert or standard assert. - No, defining a handler is orthogonal to whether assertions are enabled or not - The only difference is that _MSG allows to define a message. Unfortunately, none of those answers are true: defining NDEBUG does not disable BOOST_ASSERT (but it does disable BOOST_ASSERT_MSG -- nice inconsistency) if BOOST_ENABLE_ASSERT_HANDLER is set.

On 24/02/14 01:41, Peter Dimov wrote:

Mathias Gaunard wrote:

...

Unfortunately, none of those answers are true: defining NDEBUG does not disable BOOST_ASSERT (but it does disable BOOST_ASSERT_MSG -- nice inconsistency) if BOOST_ENABLE_ASSERT_HANDLER is set.

https://svn.boost.org/trac/boost/ticket/7028#comment:19

That doesn't change the fact that: - NDEBUG and BOOST_DISABLE_ASSERTS are inconsistent - BOOST_ASSERT and BOOST_ASSERT_MSG are inconsistent

On 24/02/14 12:59, Peter Dimov wrote:

Mathias Gaunard wrote:

...

That doesn't change the fact that: - NDEBUG and BOOST_DISABLE_ASSERTS are inconsistent

If by "inconsistent" you mean that they don't do the same thing, then yes. If they did, there would have been no need to have BOOST_DISABLE_ASSERTS.

From what I would have expected, BOOST_DISABLE_ASSERTS disables boost asserts without disabling standard asserts. This is a useful feature to have, and it is enough to justify a need for the macro. Now you may want -DNDEBUG -DBOOST_ENABLE_ASSERT_HANDLER to still keep Boost assertions but disable standard assertions. That's a valid option, but it should be done consistenly.

BOOST_DISABLE_ASSERTS disables BOOST_ASSERT(_MSG). I don't know how it can be made more consistent than that.

...

- BOOST_ASSERT and BOOST_ASSERT_MSG are inconsistent

No.

With master, -DNEBUG -DBOOST_ENABLE_ASSERT_HANDLER will disable BOOST_ASSERT_MSG, but not BOOST_ASSERT. I see the code has changed on develop, I haven't looked at it yet, hopefully it's fixed.

On 23/02/14 17:01, Klaim - Joël Lamotte wrote:

On Sun, Feb 23, 2014 at 1:58 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:

...

That's a long paper to say "we should have three levels of asserts".

Actually, no, it's more like "there is, in practice, only 3 way to manage asserts", which is explained this long certainly because it's not that obvious. In my experience, I've been using similar custom libraries than what is proposed in this paper for a long time so I believe it's 1. correct 2. useful 3. a good deep analysis.

The paper says that whether enabling some checks or not should be decided based on desired performance. It claims debug with no asserts is 20% slower than release and that debug with asserts is 300% slower than release. Not only is that highly variable (it's possible to have programs that are 100 slower in debug mode even without asserts), but it's probably not necessarily a good criterion, as it should be up to the user of the software component to decide what level of checking he wants depending on what he's doing with it rather than having a standard "build mode" mindset. Doing additional checking usually requires to store more information for debugging purposes, and that affects binary compatibility. This is the line that people usually use to choose what's enabled by default and what isn't.

Also, I belive that the fact that Bloomberg use this library internally and have been doing so for a lot of time makes their point have weight.

It has a race in the TEST_ macros. If the handler is changed in the middle of the invocation of such a test, then the change gets discarded. Being used by a big company doesn't necessarily make something bug-free.

I believe that there is no other "levels".

In practice, that's not quite what you want. You may have different components that make up your application, each of which can use asserts to validate that the input matches its contract. What you may want is to enable asserts on only parts of the application because you have already validated that your use of a certain component is correct.

What more liberty than that would you want? Or maybe you have other ideas of how such library could be designed?

Make the level an argument of the macros instead of duplicating all macros three times.

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.

On Saturday 01 March 2014 02:43:35 Peter Dimov wrote:

...

...

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3877.pdf

Assertion macros taking a level (BOOST_ASSERTL, BOOST_ASSERTL_MSG) controlled by, f.ex. BOOST_ASSERT_LEVEL (0 - opt, 1 - debug, 2 - safe) would be a relatively straightforward addition.

The N3877 approach of supplying three separate macros, one per level, has one advantage though - it doesn't generate "condition is always true/false" warnings.

Assume for instance that BOOST_ASSERTL(expr, level) is

((level) <= BOOST_ASSERT_LEVEL? BOOST_ASSERT(expr): (void)0)

Here level <= BOOST_ASSERT_LEVEL will almost always be a constant expression, hence warnings.

Leaving the note about usefulness of this warning aside, you could work around it e.g. by using preprocessor tricks: #define BOOST_ASSERTL(expr, level)\ BOOST_ASSERTL_ ## level(expr) or template specialization: #define BOOST_ASSERTL(expr, level)\ assert_impl< (level) <= BOOST_ASSERT_LEVEL >::do((expr), #expr, __FILE__, __LINE__) Of course, this would only work for compile time constant levels. The three- macros approach guarantees that so it might cause less surprises than the level-as-argument approach.