Disadvantages of macros in c language?

Answer 1

Actually macro and function are used for diff purposes.A macro replaces its expression code phisically in the code at the time of preprocessing.But in case of function the control goes to the function while executing the code.
So when the code is small then it is better to use macro.But when code is large then function should be used.

If you could get any help from the answer then plz increase my trust point.

Answer 2

The main advantage is faster execution time. Macros are always inline expanded so, while this increases code size, there is no overhead in making a function call. It is up to the programmer to decide if the increased code size is a worthwhile compromise.

However, there are two disadvantages besides the increased code size. A function evaluates to an address, whereas a macro does not. Therefore you cannot declare a pointer to a macro. Also, a function enlists the compiler to check argument types and the number of arguments, whereas the compiler can only determine the number of arguments in a macro, not their type.

Macros can also be used to declare symbolic constants. However, unlike a typed constant, a symbolic constant replaces all occurrences of the symbol with a literal, untyped constant, which results in increased code size because of the multiple instances of that literal.

There are alternatives to macros. C++ encourages programmers to enlist the compiler as much as possible to detect errors, therefore typed constants, inline functions and function templates are generally more useful than macros.

Answer 3

The only true advantage of a macro is as a conditional compilation flag for use with #ifdef. There is no other reason to use a macro.

Using a macro to emulate function overloads and templates is often cited as an advantage but it is anything but. The biggest problem with macros is that they are not type-safe and therefore undermine the strong typing of both C and C++. In addition, macros are always expanded inline and therefore do not appear in the intermediate source code, making debugging that much more difficult. Inline expansion is also a decision that is always best left to the compiler's optimisers and macros simply don't give you that option (inline expansion is not necessarily a good thing in all cases). Moreover, large macros can be confusing and difficult to manage because they must be defined on a single line. Prudent use of the backslash can help give some measure of order to them but, ultimately, they just add to the overall confusion. If a macro looks even remotely functional, then simply declare a function and be done with it.

There are some tricks and hacks that can only be done with macros, however these can only be regarded as an unintentional feature of macros, not an advantage of them. At best they are a quick-and-dirty solution. The alternative may well be more convoluted code, but at least that code would be type-safe.

Even the predefined macros can cause problems. Useful as it is to have ASSERT(), TRACE(), VERIFY(), __LINE__ and__FILE__ macros, they aren't immune to side effects. Any advantages offered by these macros is more than offset by the responsibility it enforces upon you, the programmer, to ensure you call them responsibly.

As an example of side-effects, consider the following:

ASSERT( x=1 );

This assertion will never ever assert. But what you really meant to write was:

ASSERT( x==1 );

The problem is that if you don't spot the error straight away, it is extremely difficult to find the error later. The assumption here is that you are asserting x is 1 because the code that follows relies on that fact (an invariant). In debug mode x will always be 1 because the assertion always assigns the value 1 to x. Thus the code that follows will always work as expected. But what if x were some other value prior to this assertion? Ironically, the very error this assertion was intended to catch slips completely through the net, until you build the release version and cannot fathom why it crashes. The assertion collapses to no code in release mode so x is never set to 1.

This is quite funny to watch but we've all done it at some point and it's no fun at all. The program works fine in debug mode but fails in release mode. If we're lucky we can narrow the search down to a region of code and step though it line by line, following all the function calls, but ultimately the compiler is no use to us -- which is a major disadvantage when using macros for debugging purposes!

Fortunately, this type of error is common enough that if we simply search for all assertions we can hopefully locate the one that is causing the problem fairly quickly. But it serves to highlight the major problem inherent with all macros. The onus is upon you to ensure you use them correctly. The compiler is no help whatsoever.

Another example of side-effects (a macro-defined function):

#define CUBE(A) A*A*A

int x = 2;

int y = CUBE( x );

int z = CUBE( x + y );

You might expect x to be 2, y to be 8 and z to be 1000. However, z actually evaluates to 2 + 8 * 2 + 8 * 2 + 8. Multiplication takes precedence over addition, so the evaluation is 2 + 16 + 16 + 8 = 46. To correct this particular error, we must redefine cube:

#define CUBE(A) ( (A)*(A)*(A) )

That fixes the immediate problem, but there is yet another side-effect. Try this:

int x = 2;

int y = CUBE( ++x );

We might expect x to be 3 and y to be 27, but we actually find x is really 5 and y is really 125! In other words, ++x is evaluated three times instead of once. The only way to resolve this is to make A a local variable in the macro. If that's the case then you may as well forget the macro altogether and write a function template. That way you gain the compiler's assistance and all the advantages it provides.

Answer 4

For example, name collisions may occur (especially with short, generic names like OK, min or N).