Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!mit-eddie!wuarchive!brutus.cs.uiuc.edu!apple!sun-barr!decwrl!crltrx!decvax!mcnc!rti!sheol!throopw
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.c++
Subject: Re: Debugging on the GCC and G++ compilers
Summary: I suggest fixing the general problem instead of sidestepping it
Message-ID: <0294@sheol.UUCP>
Date: 17 Dec 89 14:19:04 GMT
References: <8912111917.aa14371@ICS.UCI.EDU>
Lines: 38

> rfg@ICS.UCI.EDU
> I have never understood why rms used such an immense number of MACROS().
> [...] I personally think that this execssive use of macros is made completely
> indefensible just based on rms' own statement (in the GCC manual) that:
> "An inline function is as fast as a macro."

But there are things that can be done with macros that cannot be done
with functions in pure C, such as producing an lvalue, There are other
things that cannot be done even in pure C++, such as multiple by-name
evaluations when desired.  This was even pointed out in the description
of how to convert the one to the other and sidestep the general problem
raised here (the problem of adequate debugging support in the presence
of macros).

So, rather than railing against necessity, I'd suggest adjusting the
preprocessor to leave around some breadcrumbs so that the debugger
can evaluate the macros that the preprocessor had defined.  This scheme
could get arbitrarily complicated and hard to implement, I admit, but
the simple case of a macro defined once and left defined until the end
of the compilation would solve about 99% of the problems of debugging
with macros.

The breadcrumbs could be left in a file in the filesystem, or inserted
somehow in the compilation unit so that it would find its way into the
executable image's symbol table, or simply cause the source to be
scanned for #defines on an attempt to evaluate a macro, or any number of
other possibilities.  Thus, with much more confidence than nowadays, one
could utter most anything one sees in source code, and have it
evaluated, macros and all. 

I'm sure one of you folks tinkering with the GCC or G++ compilers could
add this in one form or another to the preprocessor.  Why not do it?
Surely it is no more difficult than replacing all macro references
in the compiler with functions and patching non-function-like macros.
And it sure would have a bigger benefit.
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org