#define macro

[boost lexical cast]

So I know using #define replaces the identifier by whatever you defined it as.

So if this is true why don't people use #define macros to make everything simpler?

Like this:

#include <iostream>
#define print(x) std::cout << x
#define endline std::endl
#define pause std::cin.ignore(); std::cin.get()
int main()
{
    print("Hello World");
    print(endline);
    pause;
    return 0;  
}

[nuderobmonkey]

Because it masks the real code. If you have an error in your code, it's much harder to detect if some of this code stuff will be changed by a macro.

[Stewbond]

Excerpt from Google C++ style guide:
https://google.github.io/styleguide/cppguide.html#Preprocessor_Macros

Be very cautious with macros. Prefer inline functions, enums, and const variables to macros. Don't use macros to define pieces of a C++ API.

Macros mean that the code you see is not the same as the code the compiler sees. This can introduce unexpected behavior, especially since macros have global scope.

The problems introduced by macros are especially severe when they are used to define pieces of a C++ API, and still more so for public APIs. Every error message from the compiler when developers incorrectly use that interface now must explain how the macros formed the interface. Refactoring and analysis tools have a dramatically harder time updating the interface. As a consequence, we specifically disallow using macros in this way. For example, avoid patterns like:

class WOMBAT_TYPE(Foo) {
  // ...

 public:
  EXPAND_PUBLIC_WOMBAT_API(Foo)

  EXPAND_WOMBAT_COMPARISONS(Foo, ==, <)
};

Luckily, macros are not nearly as necessary in C++ as they are in C. Instead of using a macro to inline performance-critical code, use an inline function. Instead of using a macro to store a constant, use a const variable. Instead of using a macro to "abbreviate" a long variable name, use a reference. Instead of using a macro to conditionally compile code ... well, don't do that at all (except, of course, for the #define guards to prevent double inclusion of header files). It makes testing much more difficult.

Macros can do things these other techniques cannot, and you do see them in the codebase, especially in the lower-level libraries. And some of their special features (like stringifying, concatenation, and so forth) are not available through the language proper. But before using a macro, consider carefully whether there's a non-macro way to achieve the same result. If you need to use a macro to define an interface, contact your project leads to request a waiver of this rule.

The following usage pattern will avoid many problems with macros; if you use macros, follow it whenever possible:

Don't define macros in a .h file.
#define macros right before you use them, and #undef them right after.
Do not just #undef an existing macro before replacing it with your own; instead, pick a name that's likely to be unique.
Try not to use macros that expand to unbalanced C++ constructs, or at least document that behavior well.
Prefer not using ## to generate function/class/variable names.

[keskiverto]

You should visit http://www.ioccc.org/

They write in C and therefore -- in lack of all the nice C++ tools -- are forced to use #define. They are rather good at using the #define ...

[boost lexical cast]

Thanks guys!

But when I use a const variable instead of a macro do I make the const variable global? Like PI = 3.14. And how to share a global const variable across multiple files?

[Handy Andy]

Hello boost lexical cast,

As I understand it you define the const global variable in only one file and in the other files you need to use it precede the definition with the key word "extern". Which tells the linker that it is defined elsewhere.

Hope that helps,

Andy

[boost lexical cast]

@Handy Andy

Thanks a lot!

[keskiverto]

You could have in a header (visible to all):

struct My {
  const static float PI;
};

And in exactly one implementation file a:
const float My::PI = 3.14;