Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!cmcl2!rna!cubsvax!peters From: peters@cubsvax.UUCP Newsgroups: net.lang.c Subject: Re: Compiler Specific Operators Message-ID: <507@cubsvax.UUCP> Date: Wed, 16-Jul-86 09:27:59 EDT Article-I.D.: cubsvax.507 Posted: Wed Jul 16 09:27:59 1986 Date-Received: Wed, 16-Jul-86 22:43:40 EDT References: <1825@uw-beaver> <503@cubsvax.UUCP> <505@cubsvax.UUCP> Reply-To: peters@cubsvax.UUCP (Peter S. Shenkin) Organization: Columbia Univ. Bio. CG Fac., NY Lines: 19 In article roy@phri.UUCP (Roy Smith) writes: >[Regarding compilers replacing calls to library routines with in-line code] > What if you want to trap and/or trace subroutine calls for >diagnostic or tuning purposes... Then you're no worse off than tracing or timing portions of your own in-line code. > ... or you want to supply your own version of the >library routine because it's faster, more accurate, or more featureful? Use a #define to a new name, or code in a new name (one of these is probably best), or disenable in-line expansion of code by means of a compile-time flag. (In one of my postings I suggested that such a flag be available, but it's probably not really necessary.) Another possibility: if the compiler knew about things like sin(x), then the -lm flag would not be necessary in programs that "call" it; thus specifying -lm could over-ride in-line expansion.... Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA