The use of macros in C + + problem detailed _c language

Macros do not follow the rules for scopes and types in C + +. This often leads to some subtle or less subtle problems. As a result, C + + provides a more suitable alternative to C + +, when it refers to C + + except for compatible C parts, such as inline functions, templates, and namespaces.

Consider:

#include "someheader.h"
struct S {
  int alpha;
  int beta;
};

If someone (unwisely) writes a macro called "alpha" or "beta", it will not be compiled or incorrectly compiled to produce unpredictable results. For example, "Someheader.h" might contain:

  #define Alpha ' a '
  #define BETA b[2]

The habit of capitalizing macros (and only macros) is helpful, but there is no protection on the language level for macros. For example, although the member's name is contained inside the structure, this does not help: the macro has processed the program as a stream of characters before the compiler can correctly identify it. Incidentally, this is one of the main reasons the C and C + + program development environment and tools can be simplified: people and compilers see different things.

Unfortunately, you can't assume that other programmers are always able to avoid something that you think is "pretty stupid". For example, I was recently reported to have encountered a macro that included Goto. I've seen this, and I've heard some--at a very fragile time--a plausible opinion. For example:

#define prefix get_ready (); int ret__
#define RETURN (i) ret__=i do_something (), goto exit
#define suffix exit:cleanup (); return ret__
V OID F () {
  prefix;
  // ...
  return (a);
  // ...
  return (x + +);
  //...
  suffix;
}

This impression is created as a maintenance programmer; "Hiding" macros into a header file--which is not uncommon--Makes the "magic" harder to discern.

A common subtle problem is that a function-style macro does not follow the rules passed by function arguments. For example:

#define Square (x) (x*x)
void F (double d, int i) {
  square (d);//Good
  Square (i++);//bad: This means (i++*i++)
  squ Are (d+1); Bad: This means (d+1*d+1); i.e. (d+d+1)
  //...
}

The issue of "d+1" can be resolved by adding a pair of parentheses to the call or macro definition:

  #define Square (x) ((x) * (x))//* This is better * *

But the question of i++ being executed two of times (probably not intentionally) still exists.

Yes, I do know that some special macros do not cause problems like C + + preprocessing macros. However, I do not want to develop the macros in C + +. Instead, I recommend using the appropriate tools in the C + + language, such as inline functions, templates, constructors (for initialization), destructors (for purging), exceptions (to exit the context), and so on.

OK, let's get here today, and then we'll go into the problem in more depth.