Hello,
I've got a pretty complicated macro inside my (unmanaged) C++ code. Is there any way to expand macros in VS debugger? Or maybe there is another way to debug macros there?
F.e. I'd like to place a breakpoint inside it.
(Yes, I know macros are bad.)
Macros are not that bad if used wisely. You can debug macros with VS macros IDE. Can read about it here: debugging macros
The compiler expands macros nicely. Get a compilation listing with the macros expanded.
Insert the expanded macro into your code. Recompile and you should be able to step through it, to do a simple test.
Generally when I am building a complicated macro, I hard code it first, and test it. Then I turn it into a macro.
For 2008, this may be of help
Go to either project or source file properties by right-clicking and going to "Properties". Under Configuration Properties->C/C++->Preprocessor, set "Generate Preprocessed File" to either with or without line numbers, whichever you prefer. This will show what your macro expands to in context. If you need to debug it on live compiled code, just cut and paste that, and put it in place of your macro while debugging.
Counter an evil with an eviler method. Expand one instance of the macro by hand, until you finish debugging, or cpp utility can help you to expand all macros, but I'm not sure if there is Windows version of it.
Have I said that the macros are very complicated? I'd like to expand one or two layers only, not all macros (otherwise it is plainly unreadable)... while debugging
If there are not way too many macros you don't want to expand, then you can simply #undef them before the snippet you want to debug. Then compile with the [Generate Preprocessed File] as mentioned above. The compilation will fail but you will get a usable snipped in the preprocessed output with the correct expansions. Copy-paste, remove the #undef-s and debug.
Sadly, your best friends for dealing with C-style macros are inline, template and a good optimizing compiler.
Use inline functions (force inlining if you really mean it) and stick to it! This will be more efficient (get only inlined if it brings performance if you optimize for perf) and maintainable. You loose much by using macros: type checking & safety.
Macros do not exist for the compiler, they only do for the preprocessor. This one makes text replacements without looking for side effects. So macros are actually never called and you cannot debug into them. No matter how you code a macro, misuse is always possible. Like in this example:
#define SQUARE(a) ((a)*(a))
Note already the ( `)´ to protect against replacements like SQUARE(3+2). But they do not protect against:
int a = 1;
int b = SQUARE(++a);
One would expect it to be 4 but you end up with 6 which is not really square. As it expands to int b = (++a)*(++a); You wouldn't have this trouble with inlined functions.
Note that the implementation of an inlined function has to be visible for the compiler at the places where you use it. Also debugging will be weird to the novice user: as there are many instances of an inlined function, you'll get a huge list of methods if you want to move the execution point to another place for example.