[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GSBug Trick #1 (was Re: ORCA/C advice needed)
- Subject: GSBug Trick #1 (was Re: ORCA/C advice needed)
- From: glyn@cs.UAlberta.CA (Reade Glyn Devin)
- Date: Mon, 22 Mar 1993 16:31:44 GMT
- Keywords: GSBug
- Newsgroups: comp.sys.apple2
- Organization: University of Alberta, Edmonton, Canada
- References: <1993Mar18.024904.11627@cbnewsd.cb.att.com> <jmk3.732437924@crux1.cit.cornell.edu>
- Sender: news@cs.UAlberta.CA (News Administrator)
In article <jmk3.732437924@crux1.cit.cornell.edu>, jmk3@crux3.cit.cornell.edu (Jay Krell) writes:
> That trick is outdated. #include <gsbug.h> and do this to break
> into a GSBug:
>
> DebugStr("\phello");
[...]
> As your code gets peppered with DebugStr (also SetMileStone), you
> should consider how it will be gotten rid of for the final version.
> One way is:
>
> #define debugstrings
> #ifndef debugstrings
> #undef DebugStr
> #undef SetMileStone
> pascal void SetMileStone(Pointer) {}
> pascal void DebugStr(Pointer) {}
> #endif
>
> #define debugstrings while in development and remove it when done.
While this is good when you want to see a working copy without the debug
code in it, it has the problem of spending cpu time and stack space on
calls to null functions. (That is, assumming that the compiler does
not eliminate this problem in optimization. I don't know if Orca/C
does it.)
Another alternative is to use a batch editor (ie: sed, perl, etc) and
delete all referenced to DebugStr( ... ); and SetMileStone( ... ); in
a _copy_ of your final program. Make sure you keep a copy of the version
with all the debug code in it for later updates ...
I prefer to use a method similar to the former when in the various
stages of debugging and the latter method only when I'm making the
final optimized version of the current release.
--Devin Reade glyn@cs.ualberta.ca