Dr. Dobb's Journal - February 2008 - (Page 69)

d02mila_p5ma 12/7/07 3:30 PM Page 69 For exception-specification testing, it is possible to specify that a certain operation should cause the raising of a specific exception. Instead, it is not feasible to specify that the compilation of a certain statement should cause a specific compilation error, as compilation errors are not standardized, and vary even with the versions of the same compiler. Therefore, we will be satisfied in distinguishing between legal code and illegal code. taining four code snippets. Three markers are used (nesting is not allowed): • @LEGAL marks the beginning of a code snippet declared as legal. • @ILLEGAL marks the beginning of a code snippet declared as illegal. • @END marks the end of the current code snippet. The example program includes statements common to every test. After these statements, there is a block of two statements declared as legal, the declaration of a vector of complex numbers, and a call to the min function with two integer numbers as parameters. These statements are actually legal. Afterwards, there is a block of two statements declared as illegal. In fact, only the second statement is illegal, as it tries to sort complex numbers. The v variable is declared twice. This is not an error, as when the first code snippet is active, the second code snippet is inactive, and vice versa; therefore, the two declarations do not coexist. Code Snippet Markers Assume you want to test the legality of 10 statements. If you put them all in the same program, you face the following difficulty: If the program can be compiled with no errors, then you infer that all 10 statements are syntactically correct. But if the compilation generates errors, it is difficult to ascertain which of the statements are syntactically incorrect. It could even be that all the statements are correct when considered one at a time, but their coexistence in the same program is incorrect. A better method would be to: • Prepare the source code of a syntactically correct program that doesn’t contain the statements to test. • Create 10 copies of this program, inserting into every copy one of the statements to test, obtaining in this way 10 different programs. • Separately compile the 10 programs. The wrong statements are the ones that made the original program no more suitable to compilation. Next, there is a code snippet containing a single statement that is declared as illegal. It is really illegal because it tries to compute the lesser between an int value and a double value. Finally, there is a code snippet of seven statements, declared as legal. Actually, this code snippet does not contain syntax errors, but the second line prints the value of a variable that has never received a value. In such a situation, many compilers emit warnings if the needed compiling options are set. This raises another issue: If a code snippet declared as legal causes the compiler to emit a warning, is the test to be considered successful or failed? And if a code snippet declared as illegal causes the compiler to emit a warning but no errors, is the test to be considered successful or failed? In a way, in both cases the test is partially successful. Consequently, there is a third possible outcome of a test: In addition to failure and success, there can be a warning. This approach is effective, but laborious for users. Therefore, it is convenient to automate it. For such purposes, you can insert the 10 statements in the same program, and submit the source code to a utility that generates the 10 versions of the source code, one for every statement to test. Of course, to let the utility know which statements to test, those statements should be adequately marked. In fact, they generally aren’t simple statements but code snippets containing one or more statements. In addition, such marking must specify whether the pointed-out code snippets are declared as legal or as illegal. Listing One is an example of a static-check program conFebruary 2008 l www.ddj.com l Dr. Dobb’s Journal 69 http://www.swellsoftware.com http://www.swellsoftware.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - February 2008

Dr. Dobb's Journal - February 2008 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook South American Software Development Conversations Inside Visual Studio 2008 BibPort: Creating Bibliographic References Continuous LINQ The ZK Framework Static Testing C++ Code The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - February 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.