macro problem

[Banfa]

I would certainly agree with that. Unfortunately students don't tend to win many marks from their teachers for providing such proofs as opposed to the answer the teacher was angling for.

[JosAH]

I would certainly agree with that. Unfortunately students don't tend to win many marks from their teachers for providing such proofs as opposed to the answer the teacher was angling for.

That reminds me of a little joke: a mathematician and a physicist were asked
the question: if you have a gas stove, an empty kettle, a water tap and a box of matches,
how do you boil water?

They both give the same sensible answer.

Then they were asked: you have a kettle filled with water on the stove, how do
you boil water?

The physicist goes: I simply light the gas and wait until the water boils in the kettle.

The mathematician: I empty the kettle and the problem is reduced to the previous problem.

kind regards,

Jos

[stdvu]

well how about this code ......... temme if its going to work or not ....... i need to submit this tagging macro problem ....... here is the code

#define SWAP(a, b) {a ^= b; b ^= a; a ^= b};
int main()
{
int x=3;
int y=6;
swap (x,y);
};

[JosAH]

Try and run it and see for yourself.

kind regards,

Jos

[Banfa]

You may wish to add statements to print the value of x and y both before and after you call your macro

[stdvu]

hmmm yeah ..... shud do that thanks a lot for help :)

[donbock]

There are a number of limitations when you try to make a macro act like a function. As Jos has already pointed out, cross-referential arguments typically lead to disaster. So do explicit side-effects, like swap(int,a++,b--). Function-like macros should be comprehensively commented to point out limitations like these.

A common idiom is to define a multi-statement macro within a do{...}while(0) block rather than naked braces as shown in reply #10. Notice the terminating semicolon is not included within the macro definition. This idiom encourages the macro call to be semi-coloned like any other statement without altering how it acts if it is within nested unbraced if statements.

Suppose you have a function that you sometimes want to override with a macro. You might want to do this to gain some execution speed at the cost of error checking and the well-known limitations of function-like macros. (This is done in the curses library.) My first suggestion is to reconsider -- perhaps inline functions will work for you. If you choose to proceed then you want to do the following. Parentheses around the function name in the prototype and function definition prevent the function name from being replaced by the macro expansion. A user who includes the header file will get the macro expansion when calling func unless they follow the #include with #undef func", in which case they call the function. Too tricky by half.

header file:
    void (func)(...);
    #define func(...) ...
C file:
    void (func)(...) {...}

On the other hand, with all the limitations of function-like macros ... a good argument can be made for not getting too good at writing them.