No, it happened again!!!!

Consider this simple macro multiply:
Here is the normal definition you would see
#define MULTIPLY(x, y) (x) * (y)
Now see what happens if you have this instead:
#define MULTIPLY(x, y) x * y


Now consider the multiply line. With out the parentheses aroudn every argument, the macro expands and the line becomes:
a = z+1 * 5;
That doesn''t evaluate to the same as
a = (z+1) * 5
Do you see? The macros are very literal in how the replace things. Not like functions...

____________________________________________________________
Direct3D vs. OpenGL

quote: Original post by maccaroo
I know it sounds like I''m pushing a point here... I''m not though. I understand what you guys say, and I''m not arguing, just trying to clear stuff in my head.

If you do use use__forceinline, and the inline function is put in there, is that slower than using a macro?

What happens with an inline function is that the assembly code rendered by the compiler is inserted at that point where the function is called. _forceinline is a MS specific feature - ie. not portable. Inlines are great, the problem is, however, that the inlining is optional - the compiler may opt not to do it.

quote: Original post by Fundy Glostna
Spontaneous macro question: Do you NEED to have brackets around every variable in a macro? It seems excessive...

#define GETMAX(A,B) (((A)>(B))?(A)B))

or could you write it like this...

#define GETMAX(A,B) ((A>B)?A:B)

Woops! That's supposed to be , a colon then bracket, not a sad face!

First off, Fundy - you can edit posts to delete them - so go back and delete those miscarriages

No you don't "need" to put those braces in, but you are well advised to do so. Consider your example and this situation:

GETMAX(a+b,c+d)

GETMAX will expand to ((a+b>c+d)? a+b:c+d)

Operator precedents can through such usage out of whack. There are a couple more examples of this in the comp.lang.c faq.


// oops, I didn't see Promit's post - he gives a better example.

[edited by - lessbread on April 12, 2002 5:35:37 PM]