[comp.lang.c] Proposal to fix the C macro deficiency

nevin1@ihlpb.ATT.COM (Liber) (09/30/88)

In article <8813@ihlpb.ATT.COM> I, Nevin Liber, wrote:

> There are a large number of functions that I would rather have as macros
> (especially when I have the same operation for different argument types),
> but can't because I'm not allowed to (in general) assume that parameters
> passed will behave as simple variables w/o side effects.

Some people have sent me email (and others have probably posted responses,
but I won't know about them; our incoming newsfeed is down again :-()
saying that what I desire can already be specified in C via the function
calling mechanism.   They are claiming that all I desire is the ability to
inline.


Function calls *don't* give me the desired semantics.  Functions are
very dependent upon the types of their parameters; macros are not.
In the case of SQUARE, for example, I would need to have a separate C
function for ints, shorts, longs, floats, and doubles.  With a macro I
would only have to declare one version and it would suffice for all cases.

Here is a first approximation of what I would like the semantics of some
macros to be (given in the form of the SQUARE example and #inline instead
of #define to declare the macro):

	#inline  SQUARE(x)  x * x
	...
	int	foo;
	int	bar;
	float	acm;
	float	ieee;
	...
	bar = 100 % SQUARE(foo++) + 1;
	ieee = SQUARE(acm -= 1.1) - 2.2;
	...

should be semantically equivalent to:

	...
	int	foo;
	int	bar;
	float	acm;
	float	ieee;
	...
	{
		int	unique_temp_1;
		unique_temp_1 = foo++;	      /*process side effects exactly once*/
		bar = 100 % (unique_temp_1 * unique_temp_1) + 1;
	}
	{
		float	unique_temp_2;
		unique_temp_2 = acm -= 1.1;   /*process side effects exactly once*/
		ieee = unique_temp_2 * unique_temp_2 - 2.2;
	}
	...

Note:  parentheses should be put around the macro expansion only when necessary
for grouping the macro as one expression such as in the int case; in the
float case, they are not necessary for grouping and an order of evaluation
should not be forced unless extra parentheses were given in the original
macro definition (assuming dpANS C, not K&R C, of course).  And, with this
parentheses rule, we could have many "x*x VS (x*x)" debates on the net. :-)

In C, I would need to declare two separately named functions to get this
effect.  In C++, I could use overloading, but I would still have to
*declare* two separate functions.  Using this proposed type of macro
expansion, however, I only need to declare the function once for different
types of parameters.

The difficulties I see with implementing this are:

1.  Although the parameter types are known at compile time, they may not
be necessarily be known at preprocessing time.

2.  Passing modifiable lvalues may be a problem.


As of now, there is no way of declaring a function once in C (or
C++, for that matter) for use with many different types of parameters, and
I feel that this would be a useful addition to the language.  I know I'm
going to regret this :-), but -- any opinions?
-- 
 _ __		NEVIN J. LIBER  ..!att!ihlpb!nevin1  (312) 979-4751  IH 4F-410
' )  )  "I catch him with a left hook. He eels over. It was a fluke, but there
 /  / _ , __o  ____  he was, lying on the deck, flat as a mackerel - kelpless!"
/  (_</_\/ <__/ / <_	These are NOT AT&T's opinions; let them make their own.