[m-dev.] for review: subdivision of mercury_trace.c
Fergus Henderson
fjh at cs.mu.OZ.AU
Thu Apr 16 13:20:12 AEST 1998
On 15-Apr-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
>
> > However, you could make mercury_trace_cmd.h a module of its own,
> > with mercury_trace_cmd.c containing only the definitions for the
> > global variables declared in mercury_trace_cmd.h.
> > This might be a better approach.
>
> MR_trace() is declared in mercury_trace.h, and those types and
> variables are *used* in MR_trace() and nowhere else (although
> they are *assigned to* in other places), so having another module
> define them would go against my sense of style. Also, this module
> would have only some global variables in it, with no code to use
> those variables, which is in itself bad. Hiding the variables
> and accessing them via function calls would cause unacceptable
> slowdown on what can be a very frequent event (calls to MR_trace).
Well, you could use macros instead of functions...
but hiding the accesses in get/set macros wouldn't buy you a lot.
Hmmm. Communication via global variables is in general bad,
but that is how we're doing things currently. A nicer solution
might be to have MR_trace_event(), MR_trace_event_internal()
and MR_trace_event_external() take a pointer to a command struct,
rather than setting global variables. The command could thus be
a local static struct in MR_trace() rather than a set of global
variables. Then mercury_trace_cmd.h would just define a struct type
rather than defining any global variables.
Comments? I'm happy to make this change myself if you're happy with it.
> > ANSI C forbids source file which are empty after preprocessing.
> > This is a dumb restriction, but we should probably respect it.
> > I'm not sure what the best fix is -- perhaps just moving the
> > #includes out of the #ifdef.
>
> We could always declare and define the exported functions,
> and then make their implementations abort if MR_USE_EXTERNAL_DEBUGGER
> is not defined. This way the space overhead will be minimal.
> Comments?
Sorry, I wasn't clear -- the restriction is only on .c files, not header
files. So you don't need to modify the header files in this way.
I think just moving the #includes in the .c file out of the #ifdef
is probably the simplest fix.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3 | -- the last words of T. S. Garp.
More information about the developers
mailing list