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