C # Preprocessor Directives

Original: C # preprocessor directives

preprocessor directives in C #

Directory

1. #define AND #undef

2. #if, #elif, #else and #endif

3. #warning and #error

4. #region and #endregion

5. #line

6. #pragma

There are many commands called preprocessor directives in C #. These commands never translate into commands in executable code, but they affect all aspects of the compilation process.

For example, you can use preprocessor directives to prevent a compiler from compiling a portion of your code. You can use these preprocessor directives if you plan to release two versions of Code, that is, the base version and the Enterprise version with more features. When compiling a basic version of the software, use preprocessor directives to prevent the compiler from compiling code that is related to additional functionality.

In addition, you can also use preprocessor directives when writing code that provides debugging information. In fact, when selling software, you generally do not want to compile this part of the code.

The preprocessor directive begins with a sign #.

C + + Developers should be aware that preprocessor directives are important in C and C + +, but in C #, there are not as many preprocessor directives, and they are less frequently used. C # provides additional mechanisms to implement the functionality of many C + + directives, such as custom features. Also note that C # does not have a standalone preprocessor like C + +, so-called preprocessor directives are actually handled by the compiler.

Nonetheless, C # retains some preprocessor directive names because they make people feel like they are pre-processors.

The following is a brief introduction to the functionality of preprocessor directives.

1. #define AND #undef

The usage of the #define is as follows: #define DEBUG

It tells the compiler that there is a symbol for the given name, in this case Debug. This is a bit like declaring a variable, but the variable does not have a real value, it just exists.

This symbol is not part of the actual code, but exists only when the compiler compiles the code. It doesn't make any sense in C # code.

#undef just the opposite-it removes the definition of the symbol: #undef DEBUG

If the symbol does not exist, #undef has no effect. Similarly, a # define does not work if the symbol already exists. You must place the # define and #undef commands at the beginning of the C # source file before you declare the code for any objects that you want to compile.

The #define itself is not useful, but it is very powerful when used in conjunction with other preprocessor directives, especially if # if.

　　There are some changes in general C # syntax that should be noted here. Preprocessor directives do not end with semicolons, there is only one command on a single line. This is because for preprocessor directives, C # no longer requires the command to be delimited with semicolons. If it encounters a preprocessor directive, it assumes that the next command is on the next line.

2. #if, #elif, #else and #endif

These instructions tell the compiler whether to compile a block of code. Consider the following method:

1 int Dosomework (double  x)2{3   // do something4    #if DEBUG5   Console.WriteLine ("" + x) ; 6   #endif 7 }

This code compiles as usual, but the Console.WriteLine command is contained within the # if clause.

This line of code executes only after the symbol debug has been defined in the previous # define command.

When the compiler encounters an # if statement, it first checks to see if the relevant symbol exists and compiles the code in the # if clause if the symbol exists. Otherwise, the compiler ignores all code until a matching #endif instruction is encountered.

In general, you define symbol debug at debug time and put debugging-related code in the # if clause. After debugging, the # define statement is commented out, all the debug code will magically disappear, the executable will be smaller, and the end user will not be confused by the debug information (obviously, to do more testing, to ensure that the code does not define debug in the case can also work).

This technique is very common in C and C + + programming, called conditional compilation (conditional compilation).

The #elif (=else if) and #else directives can be used in the # if block, meaning it is very intuitive. You can also nest # if blocks:

  #define  enterprise #define  w2k< Span style= "color: #008000;" >//  further on the file   #if  Enterprise//  do something   #if  W2k//  some code that's only relevant To Enterprise  //  edition running on W2K   #endif   #elif  Professional//  do something else   #else  //  code for the leaner version   #endif 

Unlike the case in C + +, using # If is not the only way to conditionally compile code, and C # also provides another mechanism through the conditional feature.

#if and #elif also support a set of logical operators "!", "= =", "! =" and "| | |". If the symbol exists, it is considered true, otherwise false, for example:

1 #if // if W2K is defined but ENTERPRISE isn ' t

3.#warning and #error

Another two very useful preprocessor directives are #warning and #error, which generate a warning or an error, respectively, when the compiler encounters them. If the compiler encounters a #warning instruction, the text after the #warning instruction is displayed to the user, and the compilation proceeds. If the compiler encounters the #error instruction, it will display the following text to the user as a compile error message, and then immediately exit the compilation without generating Il code.

Use these two instructions to check if a # define statement is doing something wrong, and use the #warning statement to remind yourself to perform an action:

1 #if Debug && Release2#error "You ve defined DEBUG and release simultaneously!" 3 #endif 4 #warning "Don ' t forget to remove this line before the boss tests the code!" 5 Console.WriteLine ("*i Hate this job.*");

4. #region and #endregion

The #region and #endregion directives are used to mark a piece of code as a block with the given name, as shown below.

1 #region Member Field Declarations2int  x; 3 Double D; 4 Currency balance; 5 #endregion

This does not seem to work, it does not affect the compilation process. The advantage of these directives is that they can be identified by some editors, including the visual Studio. NET Editor. These editors can use these instructions to make the code better laid out on the screen.

5. #line

#line directives can be used to change the file name and line number information that the compiler displays in warning and error messages. This instruction is not used very much.

If you are writing code, you can use this directive to change the input code with some packages before sending it to the compiler, because this means that the line number or file name that the compiler reports does not match the line number or the edited filename in the file.

#line directives can be used to restore this match. You can also use the syntax #line default to revert the line number to the line number:

1 #line // We happen to know this was line 164 in the file 2 // Core.cs, before the intermediate 3 // Package mangles it. 4 // later on 5 #line // restores default line numbering

6. #pragma

#pragma directive can suppress or restore a specified compilation warning. Unlike command-line options, #pragma directives can be executed at the class or method level, with finer control over the content of the suppressed warnings and the time to suppress them.

The following example disables the "field not used" warning, and then restores the warning after compiling the MyClass class.

1 #pragma warning Disable 1692publicclass  MyClass3{ 4   int Neverusedfield; 5 }6#pragma warning Restore 169

Thank you for watching, thank you for kissing.

Reference: "C # Advanced Programming 8th Edition"

C # Preprocessor Directives