C Preprocessor Directives

C# Preprocessor Directives

Control 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.

Language Contrast: C++Preprocessing

Languages such as C and C++ contain a preprocessor, a separate utility from the compiler that sweeps over code, performing actions based on special tokens. Preprocessor directives generally tell the compiler how to compile the code in a file and do not participate in the compilation process itself. In contrast, the C# compiler handles preprocessor directives as part of the regular lexical analysis of the source code. As a result, C# does not support preprocessor macros beyond defining a constant. In fact, the term precompiler is generally a misnomer for C#.

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


#if command

#if preprocessor-expression code #endif

#if CSHARP2 Console.Clear(); #endif

#define command

#define conditionalsymbol

#define CSHARP2

#undef command

#undef conditional-symbol

#undef CSHARP2

#error command

#error preproc-message

#error Buggy implementation

#warning command

#warning preproc-message

#warning Needs code review

#pragma command

#pragma warning

#pragma warning disable 1030

#line command

#line org-line new-line

#line 467 "TicTacToe.cs" ... #line default

#line default

#region command

#region pre-proc-message code


#region Methods ...


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

#if CSHARP2 System.Console.Clear(); #endif

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

#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.54.

Listing 3.54. 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.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

#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, 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

#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.

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

#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 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.

> 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.58, the actual line numbers within the file appear on the left.

Listing 3.58. 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.59 shows the tic-tac-toe program as an example.

Listing 3.59. 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

Essential C# 2.0
Essential C# 2.0
ISBN: 0321150775
EAN: 2147483647
Year: 2007
Pages: 185

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net