# Ifdef, # ifndef, # define, # endif Parsing

When we look at some open-source code, we often see the following scenarios:
# If defined (_ PTHREADS )&&! Defined (_ NOTHREADS)
# Define _ STL_PTHREADS
# Endif
 
# If defined (_ UITHREADS )&&! Defined (_ PTHREADS )&&! Defined (_ NOTHREADS)
# Define _ STL_UITHREADS
# Endif
 
# If defined (_ sgi )&&! Defined (_ GNUC __)
# Include <standards. h>
# If! Defined (_ BOOL)
# Define _ STL_NO_BOOL
# Endif
# If defined (_ MIPS_SIM) & _ MIPS_SIM = _ ABIO32
# Define _ STL_STATIC_CONST_INIT_BUG
# Endif
# If defined (_ WCHAR_T_IS_KEYWORD)
# Define _ STL_HAS_WCHAR_T
# Endif
#.......
# If _ COMPILER_VERSION> = 730 & defined (_ STANDARD_C_PLUS_PLUS)
# Define _ SGI_STL_USE_AUTO_PTR_CONVERSIONS
# Endif
# Endif
I used to be a cainiao and I am still a cainiao. I am confused about this full-eyed # ifdef, # ifndef, # define, # endif. I wiped it. This is a godhorse and a bird! In fact, these are Conditional compilation. For different platforms, many parameter definitions are not different, so Conditional compilation is to deal with cross-platform bombs and blow up barriers between platforms.
Let's talk about # ifndef, # define, # endif. We are very familiar with this. In many header files of our project, we often do this:
# Ifndef JSON_AUTOLINK_H_INCLUDED
# Define JSON_AUTOLINK_H_INCLUDED
 
.......
 
# Endif // json_autolink_h_receivded
This is to solve the problem of repeated definitions. For example, in. h defines class A in B. h also defines class A, so in c. cpp contains. h and B. h. According to the habit of containing the header function, this class A is repeatedly defined. In order to prevent such a situation, the above practice occurs.
Let's talk about it. # ifdef and # endif. Generally, all the rows in the source program are compiled. However, sometimes you want to compile a part of the content only when certain conditions are met, that is, to specify the compilation conditions for a part of the content. This is "Conditional compilation ". So how to use it? See the following format:
# Ifdef identifier
 
Procedure 1 www.2cto.com
 
# Else
 
Procedure 2
 
# Endif
We can choose to compile the program segment in the config file. Is that great? I don't need to write two copies, just write one copy, and then adjust the following during compilation.
For example, the following code:
# Ifdef JSON_VALUE_USE_INTERNAL_MAP
Class ValueAllocator;
Class ValueMapAllocator;
Class ValueInternalLink;
Class ValueInternalArray;
Class ValueInternalMap;
# Endif // # ifdef JSON_VALUE_USE_INTERNAL_MAP
When I didn't # define JSON_VALUE_USE_INTERNAL_MAP In the config file, the above Code was ignored. When I write this in the config file:
# Define JSON_USE_EXCEPTION 1
 
# Define JSON_VALUE_USE_INTERNAL_MAP // after this is added, the JSON_VALUE_USE_INTERNAL_MAP part of the entire project can be compiled.
 
# Ifdef JSON_IN_CPPTL
# Include <cpptl/config. h>
# Ifndef JSON_USE_CPPTL
# Define JSON_USE_CPPTL 1
# Endif
# Endif
......
# Define this item can define macros, parameters, and so on, or can be used as a valve in Conditional compilation, for example, the above example. Macro is not introduced. I don't like it very much, because I can use inline functions instead. It's a pity that inline functions are cool.
At the beginning of this article, there are many Conditional compilation statements that need to be explained.
# If defined (_ PTHREADS )&&! Defined (_ NOTHREADS) // If _ PTHREADS and _ NOTHREADS are defined, define _ STL_PTHREADS. It sounds a bit awesome!
# Define _ STL_PTHREADS
# Endif
This Conditional compilation statement is similar to if () {} else {}, which is difficult to understand. It's not a problem if it looks nice.
Finally, this article is a bit like a code post. There are not many parts of the text, so you can use the code to understand it. Sorry, please correct me. Thank you.

 

From cloud flying elephant cg