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.