Boost logo

Boost :

Subject: Re: [boost] [assert] Assert library? - Was: [regression] Where's boost/assert.hpp ??
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2014-02-23 18:10:35

On 23/02/14 17:01, Klaim - Joël Lamotte wrote:
> On Sun, Feb 23, 2014 at 1:58 PM, Mathias Gaunard <
> mathias.gaunard_at_[hidden]> 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"

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at