预处理程序如何处理宏？

Question

I am reading Efficient c++ (older version) and have some doubts. Here, for example, it says:

When you do something like this

 #define ASPECT_RATIO 1.653 

the symbolic name ASPECT_RATIO may never be seen by the compilers; it may be removed by the preprocessors before the source code ever gets compiled. As a results the ASPECT_RATIO may never get entered to SYMBOLIC_TABLE. It an be confusing if you get an error during compilation involving the constant, because the error message may refer to 1.653 and not ASPECT_RATIO

I don't understand this paragraph.How can anything be removed the preprocessor, just like that. what could be the reasons and how feasible are they in real world.

Thanks

Answer 1

It's simply a global search and replace of "ASPECT_RATIO" with "1.653" in the file before passing it to the compiler

That's why macros are so dangerous. If you have #define max 123 and a variable int max = 100 the compiler will get int 123 = 100 and you will get a confusing error message

Answer 2

I don't understand this paragraph under inverted quotes.How can anything be removed the preprocessor, just like that. what could be the reasons and how feasible are they in real world.

Basically what it describes is exactly how C and C++ pre-processor works. The reason is to replace macros/constants (that are made using the #define directive) with their actual values, instead of repeating the same values over and over again. In C++ it is considered a bad style using C-style macros, but they're supported for C compatibility.

The preprocessor, as the name suggests, runs prior to the actual compilation, and is basically changing the source code as directed through the pre-processor directives (those starting with # ). This also includes replacement of the macros with their values, the inclusion of the header files as directed by the #include directive, etc etc.

This is used in order to avoid code repetitions, magic numbers, to share interfaces (header files) and many other useful things.

Answer 3

The pre-processor will replace all instances of the token ASPECT_RATIO that appear in the code with the actual token 1.653 ... thus the compiler will never see the token ASPECT_RATIO . By the time it compiles the code, it only sees the literal token 1.653 that was substituted in by the pre-processor.

Basically the "problem" you will encounter with this approach is that ASPECT_RATIO will not be seen as a symbol by the compiler, thus in a debugger, etc., you can't query the value ASPECT_RATIO as-if it were a variable. It's not a value that will have a memory address like a static const int may have (I say "may", because an optimizing compiler may decide to act like the pre-processor, and optimize-out the need for an explicit memory address to store the constant value, instead simply substituting the literal value where-ever it appears in the code). In a larger function macro it also won't have an instruction address like actual C/C++ function will have, thus you can't set break-points inside a function macro. But in a more general sense I'm not sure I would call this a "problem" unless you were intending to use the macro as a debug-symbol, and/or set debugging break-points inside your macro. Otherwise the macro is doing its job.