Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ll-xn!adelie!axiom!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: net.lang.c
Subject: Re: Disappearing function call
Message-ID: <1865@mmintl.UUCP>
Date: Wed, 8-Oct-86 16:10:14 EDT
Article-I.D.: mmintl.1865
Posted: Wed Oct  8 16:10:14 1986
Date-Received: Fri, 17-Oct-86 03:28:36 EDT
References: <361@cullvax.UUCP> <3731@umcp-cs.UUCP>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT
Lines: 28

In article <3731@umcp-cs.UUCP> chris@umcp-cs.UUCP writes:
>The problem: to include debug calls, with variable argument lists,
>such that they may be conditionally compiled (a la #if), but without
>cluttering the source with `#ifdef'.
>
>2:	#ifdef DEBUG
>	#define	debug
>	#else
>	#define debug debug_
>	#endif
>	...
>		debug("foo(%s, %d)", foostring, foovalue);
>		...
	(the #defines here should be reversed)
>Problems: [...]
>Other compilers generate code and/or data even when DEBUG is turned
>off, since this preprocesses to
>
>		("foo(%s, %d)", foostring, foovalue);

This problem is not totally dependent on the quality of the compiler.  If
any of the arguments to the debug_ function involves a function call, the
compiler *must* generate code for it.  E.g.,

	debug("x=%d, sin(x)=%d", x, sin(x));

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Multimate International    52 Oakland Ave North    E. Hartford, CT 06108