Two Questions

[RJJ]

Hi,

Firstly, I've just taken on a large project that looks like it's been
designed by a 2 year old. It's absolutely jam packed with very large macros
which invoke other large macros that use do/while, switch/case,
token-pasting, gotos etc. which I'm finding very difficult to debug. Is
there a piece of software/utility that will unravel/unroll/convert these
ridiculous structures into inline functions, or is there a way to "force"
the complier to single step through them in debug mode (visual c++ v6.0 on
XP).

Secondly, I trying to write some information out to a file from a dll I'm
debugging. Under what circumstances would the program seem to trace through
the code on a single step debug session but not create the file on the hard
drive (discount file space, incorrect filename etc - the code works in a
separate win32 project).

Any help appreciated,

RJJ.

 

[Jens.Toerring]

Firstly, I've just taken on a large project that looks like it's been
designed by a 2 year old. It's absolutely jam packed with very large macros
which invoke other large macros that use do/while, switch/case,
token-pasting, gotos etc. which I'm finding very difficult to debug. Is
there a piece of software/utility that will unravel/unroll/convert these
ridiculous structures into inline functions, or is there a way to "force"
the complier to single step through them in debug mode (visual c++ v6.0 on
XP).

Converting a macro into a function (inline or not) can quite often
be impossible. E.g.

#define MAX( a, b ) ( a ) > ( b ) ? ( a ) : ( b )

can't be converted into a function because functions always expect
typed arguments while the macro will work with whatever types of
variables you invoke it with (and some silly games you can play with
the macro, like using it with MAX(x++, yy++)m can't be reproduced by
a function).

I guess that most compilers will allows you to just proprocess the
input file, i.e. output what the compiler really is going to see
after all the include files have been inserted and all macros have
been expanded. Then you can see what's exactly happening at the
places where the macros are used and perhaps simply get rid of them
by replacing the macros in the original code by the code generated
by the preprocessor (just be careful not to replace stuff generated
due to macros from the C header files).

Since debuggers typically just rely on the original source code
macros aren't expanded, keeping you from stepping through them.
I guess your best chance would be to take the preprocessor output
(as described above) and feed that to the compiler instead of the
original code. Then you can simply step through all the code
generated for the macros. Perhaps your debugger has some commands
that let you step through thatmacro generated code without that
trick, but there you have to ask in a newsgroup that deals with the
one you're using (and debuggers are a bit off-topic here anyway;-).

Secondly, I trying to write some information out to a file from a dll I'm
debugging. Under what circumstances would the program seem to trace through
the code on a single step debug session but not create the file on the hard
drive (discount file space, incorrect filename etc - the code works in a
separate win32 project).

The only possibility I can see is to skip in the debugger all commands
that would open the file, write to it and close the file. Why can't
you just make a backup of the file you don't want overwritten and
copy it back when you're done with debugging? (I don't know what a
"seperate win32 project" is if that's supposed to be an explanation
of why you can't do that.)
Regards, Jens

 

[Does It Matter]

Hi,

Firstly, I've just taken on a large project that looks like it's been
designed by a 2 year old. It's absolutely jam packed with very large macros
which invoke other large macros that use do/while, switch/case,
token-pasting, gotos etc. which I'm finding very difficult to debug. Is
there a piece of software/utility that will unravel/unroll/convert these
ridiculous structures into inline functions, or is there a way to "force"
the complier to single step through them in debug mode (visual c++ v6.0 on
XP).

You will probably have to get specifics from a newsgroup that deals with
your compiler but there is generally a way to retain the files generated
after pre-processing. You could tell your environment to do just the
pre-processing stage and they work with the files it generates. You'd
probably want to comment out the standard header files so they don't get
pre-processed as well.

Secondly, I trying to write some information out to a file from a dll I'm
debugging. Under what circumstances would the program seem to trace through
the code on a single step debug session but not create the file on the hard
drive (discount file space, incorrect filename etc - the code works in a
separate win32 project).

If the code is there and functional you have me stumped. I'd guess that it
is also a system specific problem. A newsgroup that deals with your
environment might be able to help you better than here.

Just a wild guess, is the file being created with an absolute path? If
not, the relative directory might not be what you expect. COM objects will
use %SystemRoot% as the current address for relative addresses.

 

[Joe Wright]

Hi,

Firstly, I've just taken on a large project that looks like it's been
designed by a 2 year old. It's absolutely jam packed with very large macros
which invoke other large macros that use do/while, switch/case,
token-pasting, gotos etc. which I'm finding very difficult to debug. Is
there a piece of software/utility that will unravel/unroll/convert these
ridiculous structures into inline functions, or is there a way to "force"
the complier to single step through them in debug mode (visual c++ v6.0 on
XP).

Secondly, I trying to write some information out to a file from a dll I'm
debugging. Under what circumstances would the program seem to trace through
the code on a single step debug session but not create the file on the hard
drive (discount file space, incorrect filename etc - the code works in a
separate win32 project).

Any help appreciated,

Hi yourself. Niether of your questions have to do with the C
programming language. You need to be somewhere people care about
Microsoft Visual Studio. Not here.

Having that off my chest, macros can be hard to read. My C compiler
allows me to write an intermediate file of the preprocessed source
in which the macros have disappeared and their results remain.