When should you use macros instead of inline functions?

Question

In a previous question what I thought was a good answer was voted down for the suggested use of macros

#define radian2degree(a) (a * 57.295779513082)
#define degree2radian(a) (a * 0.017453292519)

instead of inline functions. Please excuse the newbie question, but what is so evil about macros in this case?

Answer 1

Most of the other answers discuss why macros are evil including how your example has a common macro use flaw. Here's Stroustrup's take: http://www.research.att.com/~bs/bs_faq2.html#macro

But your question was asking what macros are still good for. There are some things where macros are better than inline functions, and that's where you're doing things that simply can't be done with inline functions, such as:

• token pasting
• dealing with line numbers or such (as for creating error messages in assert())
• dealing with things that aren't expressions (for example how many implementations of offsetof() use using a type name to create a cast operation)
• the macro to get a count of array elements (can't do it with a function, as the array name decays to a pointer too easily)
• creating 'type polymorphic' function-like things in C where templates aren't available

But with a language that has inline functions, the more common uses of macros shouldn't be necessary. I'm even reluctant to use macros when I'm dealing with a C compiler that doesn't support inline functions. And I try not to use them to create type-agnostic functions if at all possible (creating several functions with a type indicator as a part of the name instead).

I've also moved to using enums for named numeric constants instead of #define.

Answer 2

There's a couple of strictly evil things about macros.

They're text processing, and aren't scoped. If you #define foo 1, then any subsequent use of foo as an identifier will fail. This can lead to odd compilation errors and hard-to-find runtime bugs.

They don't take arguments in the normal sense. You can write a function that will take two int values and return the maximum, because the arguments will be evaluated once and the values used thereafter. You can't write a macro to do that, because it will evaluate at least one argument twice, and fail with something like max(x++, --y).

There's also common pitfalls. It's hard to get multiple statements right in them, and they require a lot of possibly superfluous parentheses.

In your case, you need parentheses:

#define radian2degree(a) (a * 57.295779513082)

needs to be

#define radian2degree(a) ((a) * 57.295779513082)

and you're still stepping on anybody who writes a function radian2degree in some inner scope, confident that that definition will work in its own scope.

Answer 3

For this specific macro, if I use it as follows:

int x=1;
x = radian2degree(x);
float y=1;
y = radian2degree(y);

there would be no type checking, and x,y will contain different values.

Furthermore, the following code

float x=1, y=2;
float z = radian2degree(x+y);

will not do what you think, since it will translate to

float z = x+y*0.017453292519;

instead of

float z = (x+y)+0.017453292519;

which is the expected result.

These are just a few examples for the misbehavior ans misuse macros might have.

Edit

you can see additional discussions about this here