Glibc header file and macro definition, glibc macro definition

Glibc header file and macro definition, glibc macro definition

The header file is nothing to mention. It is nothing more than the difference between "" and <>. It is estimated that anyone who has learned C/C ++ understands this. The current compiler has no requirements on the sequence of file inclusion, but the old C implementation is different. Of course, we do not need to worry about the header file order now.

Why should we include header files? The header file is defined. This function must be defined before any function is used. Therefore, we do not force the inclusion of header files. As long as you define the function before using the library function, Some compilers will automatically add standard library definitions. However, we recommend that you add the header file, which sometimes contains the type definition, constant definition, and macro definition.

In linux, gcc searches for the header file in the following path:/usr/local/include; libdir/gcc/target/version/include;/usr/target/include; /usr/include. The C ++ program also looks for libdir/../include/c ++/version. Target refers to the directory compiled by your GCC. Version indicates the version number.

Gcc can use-IDirThe parameter specifies the header file directory. -The nostdinc option will prevent GCC from searching for a header file directory. -Nostdinc is useful when compiling the system kernel, because the system kernel does not use the standard C library, and the kernel uses the built-in library files in the source code. Note:-nostdinc-IDir is invalid..

We can place the-I-flag anywhere in the GCC-I option parameter. In the directory before the-I-flag, we only search for header files marked by quotation marks, -The directory after I-flag searches for all header files. If you want to specify the header file directory marked by quotation marks, we do not recommend using-I-mark, but the-iquote option.

Unfortunately, you have a directory named "-". In this case, you must use-I./-to distinguish it from-I.

To prevent header files from being contained multiple times, you need to use the macro conditional statement:

/*File foo. */#ifndef FILE_FOO_SEEN#define FILE_FOO_SEEN/* *the entire file*/#endif /*!FILE_FOO_SEEN*/

This is a common structure called wrapper # ifndef

Optimization for C ++: C ++ remembers the Boolean state of wrapper # ifndef. If the second repeat contains the same header file, C ++ directly ignores the file (directly without scanning ). Comments other than wrapper # ifndef do not affect this optimization.

Generally, macro names such as FILE_FOO_SEEN in the system header file start with "_". Therefore, we recommend that you start with "_" in the personal header file to avoid conflicts.

In C ++, we have two methods to prevent the header files from being repeatedly contained, but we do not recommend them.

I. # import

# Import actually comes from the standard practice of Objective-C. It is a variant of # include. # Import contains the header file, but only once. The reason we do not recommend is: # The import permission is granted to the user, and the user must know that a header file must be included only once. However, our aim is to hand over this task to the header file.

Ii. # pragma once

# The pragma once command is used in the header file, which meets our purpose. However, not all pre-processors can recognize this command. If portability is considered, this command is obviously to be removed.

During pre-processing, the pre-processor will tell the compiler where the mark is, in fact, the line of the file. When a compilation error occurs, the compiler always prompts you which line of the error may be in that file. This is the $ line macro automatically inserted when parsing code through the syntax parser.

Some functions in glibc may be just a macro definition or a real function. This has no effect on our program. The reason for using macro-defined functions is that inline extensions can be generated, which is much faster than function calls. The disadvantage is that it is not easy to debug (because the row number provided by the compiler is not where macro-expanded, but the macro definition ). The disadvantage of macro-defined functions is that you may want to avoid using macro-defined functions. You can avoid the following two methods:

1. Add brackets to the function name.

2. Use # undef preprocessing command

For example, abs functions have both macro definitions and function implementations.

# Include <stdlib. h> abs (I); // select a macro or function call (abs) (I) based on the compiler ); // It must be a function call # undef absabs (I); // it must be a function call