This chapter is from the book
This chapter is from the book
This chapter is from the book
C# Preprocessor Directives
Control flow statements evaluate expressions at runtime. In contrast, the C# preprocessor is invoked during compilation. The preprocessor commands are directives to the C# compiler, specifying the sections of code to compile or identifying how to handle specific errors and warnings within the code. 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.
Table 3.4. Preprocessor Directives
Statement or Expression |
General Syntax Structure |
Example |
#if directive |
#if preprocessor-expression code #endif |
#if CSHARP2 Console.Clear(); #endif |
#elif directive |
#if preprocessor-expression1 code #elif preprocessor-expression2 code #endif |
#if LINUX ... #elif WINDOWS ... #endif |
#else directive |
#if code #else code #endif |
#if CSHARP1 ... #else ... #endif |
#define directive |
#define conditional-symbol |
#define CSHARP2 |
#undef directive |
#undef conditional-symbol |
#undef CSHARP2 |
#error directive |
#error preproc-message |
#error Buggy implementation |
#warning directive |
#warning preproc-message |
#warning Needs code review |
#pragma directive |
#pragma warning |
#pragma warning disable 1030 |
#line directive |
#line org-line new-line |
#line 467
|
#line default |
||
#region directive |
#region pre-proc-message code #endregion |
#region Methods ... #endregion |
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 and later 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.53.
Listing 3.53. Excluding C# 2.0 Code from a C# 1.x Compiler
#if CSHARP2 System.Console.Clear(); #endif
In this case, you call the System.Console.Clear() method, which is available only in 2.0 CLI and later versions. 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 an #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.54.
Listing 3.54. Using #if, #elif, and #endif Directives
#if LINUX ... #elif WINDOWS ... #endif
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.55.
Listing 3.55. A #define Example
#define CSHARP2
The second method uses the define option when compiling for .NET, as shown in Output 3.27.
Output 3.27.
>csc.exe /define:CSHARP2 TicTacToe.cs
Output 3.28 shows the same functionality using the Mono compiler.
Output 3.28.
>mcs.exe -define:CSHARP2 TicTacToe.cs
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.56 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.56 appear in Output 3.29.
Listing 3.56. Defining a Warning with #warning
#warning "Same move allowed multiple times."
Output 3.29.
Performing main compilation... ...\tictactoe.cs(471,16): warning CS1030: #warning: '"Same move allowed multiple times."' Build complete -- 0 errors, 1 warnings
By including the #warning directive, you ensure that 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 and later compilers provide the preprocessor #pragma directive for just this purpose (see Listing 3.57).
Listing 3.57. Using the Preprocessor #pragma Directive to Disable the #warning Directive
#pragma warning disable 1030
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. The number corresponds to the warning error number emitted by the compiler when there is no preprocessor command.
To reenable the warning, #pragma supports the restore option following the warning, as shown in Listing 3.58.
Listing 3.58. Using the Preprocessor #pragma Directive to Restore a Warning
#pragma warning restore 1030
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> Option
In addition to the #pragma directive, C# compilers generally support the nowarn:<warn list> option. This achieves the same result as #pragma, except that instead of adding it to the source code, you can 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.
> csc /doc:generate.xml /nowarn:1591 /out:generate.exe Program.cs
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.59, the actual line numbers within the file appear on the left.
Listing 3.59. The #line Preprocessor Directive
124 #line 113"TicTacToe.cs"125 #warning"Same move allowed multiple times."126 #line default
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.
Performing main compilation... ...\tictactoe.cs(113,18): warning CS1030: #warning: '"Same move allowed multiple times."' Build complete -- 0 errors, 1 warnings
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.60 shows the tic-tac-toe program as an example.
Listing 3.60. A #region and #endregion Preprocessor Directive
...
#region Display Tic-tac-toe Board
#if CSHARP2
System.Console.Clear();
#endif
// Display the current board;
border = 0; // set the first border (border[0] = "|")
// Display the top line of dashes.
// ("\n---+---+---\n")
System.Console.Write(borders[2]);
foreach (char cell in cells)
{
// Write out a cell value and the border that comes after it.
System.Console.Write(" {0} {1}", cell, borders[border]);
// Increment to the next border;
border++;
// Reset border to 0 if it is 3.
if (border == 3)
{
border = 0;
}
}
#endregion Display Tic-tac-toe Board
...
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