What is the difference between a macro and a const

问题:

I was asked this question in a technical interview:

What is the difference between a const and a macro in C++?

My answer was that a macro is a preprocessor directive and it could be difficult to debug the application if you use a macro since it is replaced with the constant expression before compilation, whereas a const can have a type identifier and is easy to debug.

Could anyone point out any other difference and which should be preferred?

EDIT:

From the IBM documentation for C++:

The following are some differences between #define and the const type qualifier:

1. The #define directive can be used to create a name for a numerical, character, or string constant, whereas a const object of any type can be declared.

2. A const object is subject to the scoping rules for variables, whereas a constant created using #define is not. Unlike a const object, the value of a macro does not appear in the intermediate source code used by the compiler because they are expanded inline. The inline expansion makes the macro value unavailable to the debugger.

3. A macro can be used in a constant expression, such as an array bound, whereas a const object cannot. (I think we surely need to use macro to define array_size.

4. The compiler does not type-check a macro, including macro arguments.

回答1:

Macros and constants are not remotely the same thing, each is sometimes appropriate for the circumstances, and your answer only scratches at the surface of the difference. Also, C++ has two different kinds of constants.

A constant defined with the const qualifier is best thought of as an unmodifiable variable. It has all the properties of a variable: it has a type, it has a size, it has linkage, you can take its address. (The compiler might optimize away some of these properties if it can get away with it: for instance, constants whose address is never used may not get emitted into the executable image. But this is only by the grace of the as-if rule.) The only thing you can't do to a const datum is change its value. A constant defined with enum is a little different. It has a type and a size, but it doesn't have linkage, you can't take its address, and its type is unique. Both of these are processed during translation phase 7, so they can't be anything but an lvalue or rvalue. (I'm sorry about the jargon in the preceding sentence, but I would have to write several paragraphs otherwise.)

A macro has far fewer constraints: it can expand to any sequence of tokens, as long as the overall program remains a well-formed program. It doesn't have any of the properties of a variable. Applying sizeof or & to a macro may or may not do something useful, depending on what the macro expands to. Macros are sometimes defined to expand to numeric literals, and such macros are sometimes thought of as constants, but they're not: "the compiler proper" (that is, translation phase 7) sees them as numeric literals.

It is generally considered good practice, nowadays, not to use a macro when a constant will do. Macros don't obey the same scoping rules as all other identifiers, which can be confusing, and if you use a constant you give more information to translation phase 7 and thus also to the debugger. However, macros permit you to do things that cannot be done any other way, and if you need to do one of those things, you should not hesitate to use them. (Macros that are pulling their weight, in this sense, generally do not just expand to numeric literals, though I am not going to say never.)

EDIT: Here's an example of a macro doing something interesting. It is in no way, shape or form a constant. There may well be a way to get the same effect without a macro (if you know one that doesn't involve stringstreams, I'd be curious to hear about it!) but I think it makes a good illustration of both the power and the danger of macros (for the latter, consider what it would do if it was used outside of one very specific context...)

static double elapsed()
{ ... }
#define ELAPSED '[' << std::fixed << std::setprecision(2) << elapsed() << "] "

// usage:
for (vector<string>::iterator f = files.begin(); f != files.end(); f++) {
    cout << ELAPSED << "reading file: " << *f << '\n';
    process_file(*f);
}

回答2:

One should prefer const int sum = 1; over #define sum 1 for a number of reasons:

Scope Based Mechanism:

#defines don't respect scopes so there is no way to create a class scoped namespace. While const variables can be scoped in classes.

Avoiding Weird magical numbers during compilation errors:

If you are using #define those are replaced by the pre-processor at time of precompilation So if you receive an error during compilation, it will be confusing because the error message wont refer the macro name but the value and it will appear a sudden value, and one would waste lot of time tracking it down in code.

Ease of Debugging:

Also for same reasons, while debugging #define would provide no help really.
To avoid both above situations const will be a better choice.

回答3:

Another difference is that a const variable has a memory and can be referenced by a pointer. Macro is just the autocomplete that will happen before compilation, hence the name is lost during compiling.

Also macro can be just more than a constant. It can be am expression or anything that is syntactically correct, even a whole definition of a function.

Macros are used to depict programming choices e.g. stack size; while cosnt is used to depict the real world constants like value of Pi or e.

回答4:

( Originally posted for static const vs #define - reproducing here as this question seems to have more "momentum"... let me know if that's inappropriate... )

Pros and cons to everything, depending on usage:

• consts
  • properly scoped / identifier clash issues handled nicely
  • strong, single, user-specified type
    • you might try to "type" a #define ala #define S std::string("abc"), but the constant avoids repeated construction of distinct temporaries at each point of use
  • One Definition Rule complications
  • can take address, create const references to them etc.
• defines
  • "global" scope / more prone to conflicting usages, which can produce hard-to-resolve compilation issues and unexpected run-time results rather than sane error messages; mitigating this requires:
    • long, obscure and/or centrally coordinated identifiers, and access to them can't benefit from implicitly matching used/current/Koenig-looked-up namespace, namespace aliases etc.
    • use of all uppercase characters is generally required and reserved for preprocessor defines (an important guideline for enterprise scale preprocessor usage to remain manageable, and which 3rd party libraries can be expected to follow), observation of which implies migration of existing consts or enums to defines involves a change in capitalisation (and hence affects client code). (Personally, I capitalise the first letter of enums but not consts, so I'd be hit here anyway - maybe time to rethink that.)
  • more compile-time operations possible: string literal concatenation, stringification (taking size thereof)
    • downside is that given #define X "x" and some client usage ala "pre" X "post", you're in trouble if you want or need to make X a runtime-changeable variable rather than a constant, whereas that transition is easier from a const char* or const std::string given they already force the user to incorporate concatenation operations.
  • can't use sizeof directly on a defined numeric constant
  • untyped (GCC doesn't warn if compared to unsigned)
  • some compiler/linker/debugger chains may not present the identifier, so you'll be reduced to looking at "magic numbers" (strings, whatever...)
  • can't take the address
  • the substituted value need not be legal (or discrete) in the context where the #define is created, as it's evaluated at each point of use, so you can reference not-yet-declared objects, depend on "implementation" that needn't be pre-included, create "constants" such as { 1, 2 } that can be used to initialise arrays, or #define MICROSECONDS *1E-6 etc. (definitely not recommending this!)
  • some special things like __FILE__ and __LINE__ can be incorporated into the macro substitution
• enums
  • only possible for integer values
  • properly scoped / identifier clash issues handled nicely
  • strongly typed, but to a big-enough signed-or-unsigned int size over which you have no control (in C++03)
  • can't take the address
  • stronger usage restraints (e.g. incrementing - template <typename T> void f(T t) { cout << ++t; } won't compile)
  • each constant's type taken from the enclosing enum, so template <typename T> void f(T) get a distinct instantiation when passed the same numeric value from different enums, all of which are distinct from any actual f(int) instantiation.
  • even with typeof, can't expect numeric_limits to provide useful insight
  • the enum's typename may appear in various places in RTTI, compiler messages etc. - possibly useful, possibly obfuscation

As a general rule, I use consts and consider them the most professional option for general usage (though the others have a simplicity appealing to this old lazy programmer).

回答5:

Macros don't respect scope, and a macro's name may not be available to a symbolic debugger. Dan Saks has a fairly complete article on the relative merits of macros (none), constant objects, and enumeration constants. Like Stephen Dewhurst, Saks prefers enumeration constants for integer values since they take up no storage (more precisely, enumeration constants have neither storage duration nor linkage).

回答6:

define can be redefine , but const will be cause compiler error:

sample: source : main.cpp

#define int_constance 4
#define int_constance 8 // ok, compiler will warning ( redefine macro)

const int a = 2;
const int a = 4; // redefine -> error

int main(int argc, char** argv)
{
   std::cout << int_constance ; // if remove second #define line, output will be 8

   return 0;
}

回答7:

A macro always have a type, for instance, #define FIVE 5 is of type int.

An advantage for the const variable over the macro could be the memory usage : With a macro the value may have to be duplicated everywhere it is used will a const variable will not be duplicated in memory. (but I am not sure of this difference)