TEKPOOL

Heres what stroustrop has to say about MACRO's

So, what's wrong with using macros?
Macros do not obey the C++ scope and type rules. This is often the cause of subtle and not-so-subtle problems. Consequently, C++ provides alternatives that fit better with the rest of C++, such as inline functions, templates, and namespaces.
Consider

#include "someheader.h"

struct S {
int alpha;
int beta;
};

If someone (unwisely) has written a macro called "alpha" or a macro called "beta" this may not compile or (worse) compile into something unexpected. For example, "someheader.h" may contain
#define alpha 'a'
#define beta b[2]

Conventions such as having macros (and only macros) in ALLCAPS helps, but there is no language-level protection against macros. For example, the fact that the member names were in the scope of the struct didn't help Macros operate on a program as a stream of characters before the compiler proper sees it. This, incidentally, is a major reason for C and C++ program development environments and tools have been unsophisticated the human and the compiler see different things.
Unfortunately, you cannot assume that other programmers consistently avoid what you consider "really stupid". For example, someone recently reported to me that they had encountered a macro containing a goto. I have seen that also and heard arguments that might - in a weak moment - appear to make sense. For example

#define prefix get_ready(); int ret__
#define Return(i) ret__=i; do_something(); goto exit
#define suffix exit cleanup(); return ret__

void f()
{
prefix;
// ...
Return(10);
// ...
Return(x++);
//...
suffix;
}

Imagine being presented with that as a maintenance programmer; "hiding" the macros in a header - as is not uncommon - makes this kind of "magic" harder to spot.
One of the most common subtle problems is that a function-style macro doesn't obey the rules of function argument passing. For example

#define square(x) (x*x)

void f(double d, int i)
{
square(d); // fine
square(i++); // ouch means (i++*i++)
square(d+1); // ouch means (d+1*d+1); that is, (d+d+1)
// ...
}

The "d+1" problem is solved by adding parentheses in the "call" or in the macro definition
#define square(x) ((x)*(x)) /* better */

However, the problem with the (presumably unintended) double evaluation of i++ remains.
And yes, I do know that there are things known as macros that doesn't suffer the problems of C/C++ preprocessor macros. However, I have no ambitions for improving C++ macros. Instead, I recommend the use of facilities from the C++ language proper, such as inline functions, templates, constructors (for initialization), destructors (for cleanup), exceptions (for exiting contexts), etc.

http//www.research.att.com/~bs/bs_faq2.html#macro.

ya u r rite.. post increment is done after all operations , that's we get 100
if we use square(i++)

The above explanation was right, but

i = 10 ;
square(++i);

wud return 12*12 and not 11*12.

the reason is preincrement has higher precedence than multiplication..

so, square(++i) is replaced by (++i )* (++i) ..