Assertion (software development): Difference between revisions

Revision as of 06:29, 29 October 2019

Revision as of 15:41, 27 January 2020

Line 111:

</source>

If the <code>(BOOLEAN CONDITION)</code> part evaluates to false then the above code will not compile because arrays may not have a negative length. If in fact the compiler allows a negative length then the initialization byte (the <code>'!'</code> part) should cause even such over-lenient compilers to complain. The boolean expression must be a compile-time constant value, for example <code>(sizeof(int) == 4)</code> would be a valid expression in that context.

Both of these methods require a method of constructing unique names. Modern compilers support a <code>__COUNTER__</code> preprocessor define that facilitates the construction of unique names, by returning monotonically increasing numbers for each compilation unit.<ref>[https://gcc.gnu.org/gcc-4.3/changes.html GNU, "GCC 4.3 Release Series&nbsp;— Changes, New Features, and Fixes"]</ref>

Line 121:

Most languages allow assertions to be enabled or disabled globally, and sometimes independently. Assertions are often enabled during development and disabled during final testing and on release to the customer. Not checking assertions avoids the cost of evaluating the assertions while (assuming the assertions are free of [[Side-effect (computer science)|side effects]]) still producing the same result under normal conditions. Under abnormal conditions, disabling assertion checking can mean that a program that would have aborted will continue to run. This is sometimes preferable.

Some languages, including [[C (programming language)|C]] and [[C++]], completely remove assertions at compile time using the [[preprocessor]]. Java requires an option to be passed to the run-time engine in order to enable assertions. Absent the option, assertions are bypassed, but they always remain in the code unless optimised away by a JIT compiler at run-time or excluded by an <code>if (false)</code> condition at compile time, thus they need not have a run-time space or time cost in Java either.

Programmers can build checks into their code that are always active by bypassing or manipulating the language's normal assertion-checking mechanisms.