Boost logo

Boost :

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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk