a reasonable approach to inlining

[Chris Torek]

In article <6667 at sigi.Colorado.EDU> ziel at spot.Colorado.EDU (ZIEL FRED ADAM)
writes:
>... Microsoft ... C 5.0 ... "intrinsic" functions.  These are standard
>library functions such as movmem, strcmp, strcpy, inp, outp, etc. that
>are inlined.  The instrinisic code generation can be turned on and off
>individually for each function using a #pragma.

The dpANS provides for inline generation in a different way:  For
instance,

	#include <math.h>
	...
		double low; ... low = floor(arg);

might generate floor inline, while

	#include <math.h>
	#undef floor
	...
		double low; ... low = floor(arg);

will refer to a library routine.

Note that this makes it difficult to temporarily refer to the library
version; with #pragma one can presumably turn inlining back on later.
I do not know whether the dpANS allows a second

	#include <math.h>

to turn floor back into an inline.

>... They also have #pragma's to control the optimizations ...  ie.
>optimized null delay loops don't serve their purpose if they are
>optimized away ...

This, incidentally, is yet another reason that either pragmas should
not be like `preprocessor' controls, or that `#define' macros should be
allowed to expand to such controls.  A delay macro like

	#define	DELAY(n) {int delay_tmp = (n); while (delay_tmp--) /*void*/;}

should clearly disable optimisation, yet if this is to be done with
`#pragma', we need something like

	#define DELAY(n) { \
		int delay_tmp = (n); \
		#pragma optimisation: push state \
		#pragma optimisation: none \
		while (delay_tmp--) /*void*/; \
		#pragma optimisation: pop state \
	}

but by all the rules, these `#pragma's are in the wrong place.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris