What is the benefit of using #define to declare a constant?

Question

I have seen a lot of programs using #define at the beginning. Why shouldn't I declare a constant global variable instead ?

Answer 1

(This is a C++ answer. In C, there is a major advantage to using macros, which is that they are pretty much the only way you can get a true constant-expression.)

---

What is the benefit of using #define to declare a constant?

There isn't one.

I have seen a lot of programs using #define at the beginning.

Yes, there is a lot of bad code out there. Some of it is legacy, and some of it is due to incompetence.

Why shouldn't I declare a constant global variable instead ?

You should.

A const object is not only immutable, but has a type and is far easier to debug, track and diagnose, since it actually exists at compilation time (and, crucially, has a name in a debug build).

Furthermore, if you abide by the one-definition rule, you don't have to worry about causing an almighty palaver when you change the definition of a macro and forget to re-compile literally your entire project, and any code that is a dependent of that project.

And, yes, it's ironic that const objects are still called "variables"; of course, in practice, they are not variable in the slightest.

Answer 2

What is the benefit of using #define to declare a constant?

Declaring a constant with #define is a superior alternative to using literals and magic numbers (that is, code is much better off with a value defined as #define NumDaysInWeek (7) than simply using 7), but not a superior alternative to defining proper constants.

You should declare a constant instead of #define-ing it, for the following reasons:

• #define performs a token/textual replacement in the source code, not a semantic replacement.

  This screws up namespace use (#defined variables are replaced with values and not containing a fully qualified name).

  That is, given:

  namespace x {
  #define abc 1
  }
  

  x::abc is an error, because the compiler actually tries to compile x::1 (which is invalid).

  abc on the other hand will always be seen as 1, forbidding you from redefining/reusing the identifier abc in any other local context or namespace.

• #define inserts it's parameters textually, instead of as variables:

  #define max(a, b) a > b ? a : b;
  
  int a = 10, b = 5;
  int c = max(a++, b); // (a++ > b ? a++ : b); // c = 12
  

• #define has absolutely no semantic information:

  #define pi 3.14 // this is either double or float, depending on context
  
  /*static*/ const double pi = 3.14; // this is always double
  

• #define makes you (the developer) see different code than the compiler

  This may not be a big thing, but the errors created this way are obscure, unexpected and waste a lot of time (you could look at an error, where the code looks perfectly fine to you, and curse the compiler for half a day, only to discover later, that one of the symbols in your expression actually means something completely different).

  If you get with a debugger to code using one of the declarations of pi above, the first one will cause the debugger to tell you that pi is an invalid symbol.

Edit (valid example for a local static const variable):

const result& some_class::some_function(const int key) const
{
   if(map.count(key)) // map is a std::map<int,result> member of some_class
       return map.at(key); // return a (const result&) to existing element
   static const result empty_value{ /* ... */ }; // "static" is required here
   return empty_value;  // return a (const result&) to empty element
}

This shows a case when you have a const value, but it's storage needs to outlast the function, because you are returning a const reference (and the value doesn't exist in the data of some_class). It's a relatively rare case, but valid.

Answer 3

According to the "father" of C++, Stroustroup, defining constants using macros should be avoided.

The biggest Problems when using macros as constants include

• Macros override all occurrences in the code. e.g. also variable definitions. This may result in compile Errors or undefined behavior.
• Macros make the code very difficult to read and understand because the complexity of a macro can be hidden in a Header not clearly visible to the programmer