Compiler Specific Operators

[chris at umcp-cs.UUCP]

>In article <mit-eddi.2526> barmar at mit-eddie.UUCP (Barry Margolin) writes:
>>...why not write the operations as function calls, and teach compilers
>>to open-code calls to certain functions.

In article <503 at cubsvax.UUCP> peters at cubsvax.UUCP (Peter S. Shenkin) replies:
>Yes;  I tried to send off a similar comment on the original posting, but
>it never made it off site.  What I'd like to know is whether the draft
>standard permits this, and what the net guru's think about it.
>
>In Chris Torek's comment on the original posting, he proposes a workaround
>permitted by the draft ANSI, and notes that it is bug-prone.  If this means
>that the draft standard doesn't permit "function calls" to be implemented 
>otherwise, I'm curious what the objections are to this practice.

Actually, the workaround comes off as being recommended by the
draft standard, at least to me.  I am not certain it is bug-prone,
but it sure does `feel' odd.

Apparently the committee (or a large faction thereof) is quite
concerned about ensuring that there is some easy way to ensure a
`real function call'.  They want a standardised way of defeating
in-line expansion, and have, at least for the nonce, settled upon
`#undef funcname'.  A `#pragma' seems to me to be at least as good
an idea; compilers that never open-code a function call can ignore
this, while those that might perform this optimisation could be
required to pay attention to at least this one pragma.  Then instead
of

	#include <math.h>
	#undef sin			/* make sure we get a function */
	...

we might have

	#include <math.h>
	#pragma disable_inline(sin)	/* get a function */
	...
	#pragma enable_inline(sin)	/* back to possible inline */
	...
	#pragma disable_inline(sin)	/* back to function */

This has the advantage of being reversible, as well.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu