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.

UPDATE 2023: Seven years after I originally asked this question, I noticed that Visual Studio 17.5.0 finally allows you to see the expansion of #define's

Answer 1

Select the macro you are interested in, on the line you want to know its value.

Press F12.

This will jump to its definitions (as best the compiler can work out: a given line of code could have multiple definitions for the same #define!).

Answer 2

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 3

The why they are not known has been answered.. I actually feel your pain. That's why for every project I start I actually keep track of the include paths, and before compiling I grep the paths to get the define's in a textfile which list the defines. I keep that at hand when debugging. It's a trick I guess :)

addition : Maybe really helpful.. I hope :) I'm not using the Visual Studio anymore myself, so I'm not 100% sure if it is possible in 2015, but : - set preprocess to a file to yes in configuration properties -> C / C++ -> preprocessor. - visual studio used to generate an .i file, and I hope 2015 still does the same, the next time you compile your program, since this is the output of the preprocessor. - opening this .i file, you can at least see what the actual expanded value of your macro is, and also enter this value in the watch window, while you are debugging.

that would just cost you an extra compilation, but help you 2nd time around, saving you precious time, you can spend on other things than folder-diving :)

Answer 4

'#Define'd constants are unknown to the debugger as they are preprocessed before compilation and their appearances in the code are substituted with the value.

If you want a constant value why not use const? That way you can see the value in the debugger and also enforce the compiler to check for anywhere you mistakenly try to change the value in the code. #define has none of that safety.

Answer 5

#define one 1

This is just text replacement. Even compiler do not know what is behind this "1" in code.

Macros are evaluated by preprocessor before compilation/linking stage.

More about compilation steps: How does the compilation/linking process work?

Answer 6

Regarding "Visual Studio", the #define X 3 is parsed during the pre-processing and all appearances of X are replaced with 3. Thus when you move your mouse over it, the debugger won't show its value, like in any other statement that has 'hardcoded' value.

int res = y + 3;

If you move the mouse over 3 it won't show you 3 in a floating window.

Answer 7

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.