Why aren't #define'd constants known to debugger?

Question

When debugging my code I quite often want to know the value of #define'd constants. But the debugger does not appear to know their values. This means I have to chase around looking at include paths etc to find the #define line. Is there some trick to make this easier?

UPDATE: I had to award the green tick to Tony D for his detailed answer of the headline question, but I have also upvoted the use of const instead of #define (I also tested that enum works too). Finally the use of F12 to find the original #define line was another good idea.

Answer 1

For whatever 10 minutes on Google's worth, it seems Visual Studio doesn't support this.

Some compilers do attempt this, but there's a reason it's a bit fragile / best-effort...

To first rehash and knock down the common but bogus explanation for this: there's a conceptually distinct preprocessing step that substitutes text for the uses of preprocessor macros before "proper" compilation begins, but there's really no reason the preprocessing stage can't pass a record of the #define and #undefine statements onwards for inclusion with other debug information.

What is a pain is that what is intuitively and commonly considered "#define-ing a preprocessor constant" isn't anything like...

const Some_Type some_identifier = some_value; 

...in that the latter has a specific location in the application's namespace heirarchy and really can't be changed, while a #define can be #undef-ined and re-#defined any number of times, such that the "value" of a preprocessor macro at a particular line of code can depend on how that line's been included in the translation unit: each inclusion of the same line in each translation unit could have a different value (or no value) for that macro.

For this reason, displaying the "value" of a macro as you're debugging through some code is problematic - it's only guaranteed to have a single value at a particular line in a particular translation unit, but programmers normally want debuggers to show and navigate programs in terms of lines in source files.

Consider:

use_x.h

class T ## X {     void g() { ... } }; 

some_app.cc

#define X 2783 #include "use_x.h" #undef X #define X 2928 #include "use_x.h" void f() {     const int last_x = X; } 

If your debugger's stepping through f() above, X can be said to be 2928, but what if you're stepping through a version of g() - the debugger would have a tough time understanding there's some connection between the class name and the value of X used to create it, or working out what to display some other way....

It gets worse if you hover a mouse over a macro while stopped at some other line - possibly linked in from a different translation unit - it can be impossible for the debugger to know whether you're interested in the last value of that macro that your execution has passed through, or the next value it might have if execution continues (if it can even predict any branching that may happen first), or the value (if any) of the macro at the line the debugger's stopped at.

So, some tool chains (compilers / debug-info-encodings / debuggers) just don't buy into this mess. Better tools might track simple cases then display nothing - or a list of possible values - for cases too complex to analyse. Displaying wrong values is much worse than nothing.

---

It doesn't help within the debugger, but when macro values/substitutions need to be reviewed you can try cl /E (for GCC/clang the option's -E) to provide preprocessed output for a translation unit - you can then see what substitutions have been made by the preprocessor.

Answer 2

Macros are evaluated and resolved by the preprocessor, before compilation. It's not just that the compiled program doesn't know their values: the compiled program contains no trace of them at all. There's nothing for your debugger to inspect.

Consider macros to be a code generation tool, and everything will become clear.

Some compilers do have a flag you can set to retain the values of various preprocessor definitions and list them in a special area with your executable for debugging purposes. I don't know how to get that to happen in VS, though. I would instead use the relevant switch for only running the preprocessor, then inspect the result.