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: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2014-02-24 14:10:32

On Mon, Feb 24, 2014 at 12:10 AM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> wrote:

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

My understanding was that it was the actual point of the paper?

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

>
>
>  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.
>
>
>
Of course it's not bug-free, it's not what I was saying either. I was
pointing credibility from my personal perspective.
Most Boost libraries are full of bugs, they are still high standard.
Anyway...

>
>  I believe that there is no other "levels".
>>
>
> In practice, that's not quite what you want.
>

I would say: that's the minimum of what I 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.
>
>
This would be an interesting feature (per-library behaviour). However I
fail to see that would be implemented in a generic way.
Or do you mean using test macro arguments as library identifiers?

>
>
> > 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.
>
>
It's not clear to me if you mean that doing this change would help having
per-library assertion behaviour, or if you're just direcly answering my
questions in an unrelated way?