Re: Two Questions
Jens.Toerring_at_physik.fu-berlin.de
Date: 08/11/04
- Next message: jacob navia: "Re: Signed and unsigned int"
- Previous message: Keith Thompson: "Re: File seek"
- In reply to: RJJ: "Two Questions"
- Next in thread: Does It Matter: "Re: Two Questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 11 Aug 2004 18:15:32 GMT
RJJ <RJJinvalid@munged.c0m> wrote:
> 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
-- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de
- Next message: jacob navia: "Re: Signed and unsigned int"
- Previous message: Keith Thompson: "Re: File seek"
- In reply to: RJJ: "Two Questions"
- Next in thread: Does It Matter: "Re: Two Questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
