Experimental Physics and Industrial Control System
Hi Jeff,
Jeff Hill wrote:
The question comes up from time to time about whether NDEBUG should be set
when it's an optimized build (that's not currently the case). There are two
issues.
The first one is whether assert tests should remain in optimized builds or
not. I can argue on both sides of that one, but maybe not today ;-)
I think the response to that when you brought it up last week was that
we should keep our current assertion tests live in production builds.
The second one is what to do with similar types of consistency checking that
clearly have very negative performance impacts on the production system, but
nevertheless should be checked (maybe only in debug builds) during
regression testing. An example are features in the EPICS mutex that verifies
that the same thread that locks the mutex is also unlocking it (on certain
os this is already provided in the debug version of the runtime library I
suspect). There are more concerns about this type of bogosity when Guard
classes are in use because it's easier for a misguided developer to place a
Guard in other than automatic (stack) type of variable. A parallel situation
exists also with the Guard releasing class (maybe the os specific debug
version of the runtime library can't help us with this one). Furthermore,
with the guard releasing class it's easier to make dumb mistakes (I have to
admit that this comes from personal experience with misusing the guard
releasing class).
Based on the above two paragraphs I think I am starting to see that maybe we
have two reputable options.
1) Set NDEBUG in optimized builds and use it to remove the high overhead
stuff also.
Don't like, we see quite a few bug reports from assertions firing — just
search tech-talk for 'assert' to see that.
2) Standardize throughout base on a new flag controlling the removal of high
overhead consistency checking code and set this flag by default in
production (optimized) builds.
If you're thinking about adding some expensive consistency checking that
will significantly affect performance when enabled then I fully agree to
having them disabled in production builds. However I don't particularly
like the idea of having them enabled whenever the OPT flag is off, since
it then becomes hard to separate out bugs that are caused by a compiler
when optimization is turned on; I'd much prefer a separate switch which
can be set on a per-subsystem or even per-compilation unit basis,
separate from the compiler optimization switch.
- Andrew
--
When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something
is impossible, he is very probably wrong. -- Arthur C. Clarke
- Replies:
- Re: NDEBUG Ben Franksen
- Navigate by Date:
- Prev:
Problems with bug in make 3.81 Ralph Lange
- Next:
Re: NDEBUG Ben Franksen
- Index:
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Problems with bug in make 3.81 Ralph Lange
- Next:
Re: NDEBUG Ben Franksen
- Index:
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024