|Asserts & optimisation (repost from com.lang.c++) firstname.lastname@example.org (David Fisher) (2003-12-03)|
|Re: Asserts & optimisation (repost from comp.lang.c++) email@example.com (2003-12-08)|
|Re: Asserts & optimisation (repost from com.lang.c++) firstname.lastname@example.org (2003-12-08)|
|From:||"David Fisher" <email@example.com>|
|Date:||3 Dec 2003 20:28:32 -0500|
|Organization:||Pacific Internet (Australia)|
|Posted-Date:||03 Dec 2003 20:28:32 EST|
This comment from jeffc sparked a thought:
> The assert doesn't do anything in a release build, and that
> is its advantage, you can afford to put more tests into your
> code then you ever would if the tests were to be exercised
> in release versions.
> Would we ever put a check for validity into every method of
> our Point class if it were to be exercised in customer
> builds? Of course not, the test will be exercised millions
> of times
Error checking (and recovery) in itself isn't a bad thing in a release
build - it's the cost that people object to. A really clever compiler
could potentially take care of this problem - for example:
T& Array::operator  (int index)
assert(index >= 0 && index < arrayLength);
void incrementValues(Array &a)
for (int n = 0;n < a.length();++n)
An intelligent compiler could recognise that in this particular loop,
the assert condition is always false, and so the check is not
necessary at run time.
Has anyone ever seen an optimising compiler that actually does
This would require:
- data flow analysis across function boundaries
- some way of preventing execution of the "assert" code:
- multiple entry points to functions with preconditions ?
- multiple versions of functions, with and without checks ?
(similar to the code generation done by templates)
(but avoid having 2^N versions of a function with N asserts !)
- possibly embedding this information in object modules / libraries
so separate compilation is handled, too
This applies to "optimising out" any block of code the compiler
knows will never be entered, not just asserts like this one.
Return to the
Search the comp.compilers archives again.