C Preprocessor Directives
C# Preprocessor DirectivesControl flow statements evaluate conditional expressions at runtime. In contrast, the C# preprocessor is invoked during compilation. The preprocessor commands are directives to the C# compilers specifying the sections of code to compile and identifying how to handle specific errors and warnings. C# preprocessor commands can also provide directives to C# editors regarding the organization of code.
Each preprocessor directive begins with a hash symbol (#), and all preprocessor directives must appear on one line. A newline rather than a semicolon indicates the end of the directive. A list of each preprocessor directive appears in Table 3.4.
Excluding and Including Code (#if, #elif,#else, #endif)Perhaps the most common use of preprocessor directives is in controlling when and how code is included. For example, to write code that could be compiled by both C# 2.0 compilers and the prior version 1.2 compilers, you use a preprocessor directive to exclude C# 2.0-specific code when compiling with a 1.2 compiler. You can see this in the tic-tac-toe example and in Listing 3.52. Listing 3.52. Excluding C# 2.0 Code from a C# 1.x Compiler
In this case, you call the System.Console.Clear() method, which is available only in the 2.0 CLI version. Using the #if and #endif preprocessor directives, this line of code will be compiled only if the preprocessor symbol CSHARP2 is defined. Another use of the preprocessor directive would be to handle differences among platforms, such as surrounding Windows- and Linux-specific APIs with WINDOWS and LINUX #if directives. Developers often use these directives in place of multiline comments (/*...*/) because they are easier to remove by defining the appropriate symbol or via a search and replace. A final common use of the directives is for debugging. If you surround code with a #if DEBUG, you will remove the code from a release build on most IDEs. The IDEs define the DEBUG symbol by default in a debug compile and RELEASE by default for release builds. To handle an else-if condition, you can use the #elif directive within the #if directive, instead of creating two entirely separate #if blocks, as shown in Listing 3.53. Listing 3.53. Using #if, #elseif, and #endif Directives
Defining Preprocessor Symbols (#define, #undef)You can define a preprocessor symbol in two ways. The first is with the #define directive, as shown in Listing 3.54. Listing 3.54. A #define Example
The second method uses the define option when compiling for .NET, as shown in Output 3.27. Output 3.27.
Output 3.28 shows the same functionality using the Mono compiler. Output 3.28.
To add multiple definitions, separate them with a semicolon. The advantage of the define complier option is that no source code changes are required, so you may use the same source files to produce two different binaries. To undefine a symbol you use the #undef directive in the same way you use #define. Emitting Errors and Warnings (#error, #warning)Sometimes you may want to flag a potential problem with your code. You do this by inserting #error and #warning directives to emit an error or warning, respectively. Listing 3.55 uses the tic-tac-toe sample to warn that the code does not yet prevent players from entering the same move multiple times. The results of Listing 3.55 appear in Output 3.29. Listing 3.55. Defining a Warning with #warning
Output 3.29.
By including the #warning directive, the compiler will report a warning, as shown in Output 3.29. This particular warning is a way of flagging the fact that there is a potential enhancement or bug within the code. It could be a simple way of reminding the developer of a pending task. Turning Off Warning Messages (#pragma)Warnings are helpful because they point to code that could potentially be troublesome. However, sometimes it is preferred to turn off particular warnings explicitly because they can be ignored legitimately. C# 2.0 provides the preprocessor #pragma directive for just this purpose (see Listing 3.56). Listing 3.56. Using the Preprocessor #pragma Directive to Disable the #warning Directive
Note that warning numbers are prefixed with the letters CS in the compiler output. However, this prefix is not used in the #pragma warning directive. To re-enable the warning, #pragma supports the restore option following the warning, as shown in Listing 3.57. Listing 3.57. Using the Preprocessor #pragma Directive to Restore a Warning
In combination, these two directives can surround a particular block of code where the warning is explicitly determined to be irrelevant. Perhaps one of the most common warnings to disable is CS1591, as this appears when you elect to generate XML documentation using the doc compiler option, but you neglect to document all of the public items within your program. nowarn:<warn list> OptionIn addition to the #pragma directive, C# compilers generally support the nowwarn:<warn list> option. This achieves the same result as #pragma, except that instead of adding it to the source code, you can simply insert the command as a compiler option. In addition, the nowarn option affects the entire compilation, and the #pragma option affects only the file in which it appears. Turning off the CS1591 warning, for example, would appear on the command line as shown in Output 3.30. Output 3.30.
Specifying Line Numbers (#line)The #line directive controls on which line number the C# compiler reports an error or warning. It is used predominantly by utilities and designers that emit C# code. In Listing 3.58, the actual line numbers within the file appear on the left. Listing 3.58. The #line Preprocessor Directive
Including the #line directive causes the compiler to report the warning found on line 125 as though it was on line 113, as shown in the compiler error message shown in Output 3.31. Output 3.31.
Following the #line directive with default reverses the effect of all prior #line directives and instructs the compiler to report true line numbers rather than the ones designated by previous uses of the #line directive. Hints for Visual Editors (#region, #endregion)C# contains two preprocessor directives, #region and #endregion, that are useful only within the context of visual code editors. Code editors, such as the one in the Microsoft Visual Studio .NET IDE, can search through source code and find these directives to provide editor features when writing code. C# allows you to declare a region of code using the #region directive. You must pair the #region directive with a matching #endregion directive, both of which may optionally include a descriptive string following the directive. In addition, you may nest regions within one another. Again, Listing 3.59 shows the tic-tac-toe program as an example. Listing 3.59. A #region and #endregion Preprocessor Directive
One example of how these preprocessor directives are used is with Microsoft Visual Studio .NET. Visual Studio .NET examines the code and provides a tree control to open and collapse the code (on the left-hand side of the code editor window) that matches the region demarcated by the #region directives (see Figure 3.5). Figure 3.5. Collapsed Region in Microsoft Visual Studio .NET |
