What is the difference between a macro and a function in C?

Question

What is the difference between a macro and a function in C? Please tell me one application where I can use macros and functions?

Solution 1

The basic difference is that function is compiled and macro is preprocessed. When you use a function call it will be translated into ASM CALL with all these stack operations to pass parameters and return values. When you use a MACRO, C preprocessor will translate all strings using macro and than compile.

Minus of using macros is that they hide implementation. Its way harder to find bug if have one.

Solution 2

In C (and C++) a macro is a preprocessor directive. This means that before your program starts compiling it will go through and process all your macros. Macros are useful because

• They can make your program easier to read
• They can improve efficiency (as they can be calculated at compile time)
• They can shorten long or complicated expressions that are used a lot. For example, we use a macro to get the current log4cpp logger and another few to write to it with various levels.

Disdvatages

• Expand the size of your executable
• Can flood your name space if not careful. For example, if you have too many preprocessor macros you can accidentally use their names in your code, which can be very confusing to debug.

Example

#define INCREMENT(x) x++

A function is a piece of code that can relatively independently be executed and performs a specific task. You can think of it sort of like a mathematical function: a function given a set of inputs will give a particular output. In C these are defined as

<return type> <name>(<parameters>)
{
  //code body
}

Solution 3

You have to think the macro just as a text replacement: is like you inline the macro code every time you see the macro in your code. This is good for "code snippets" because you avoid the function calling overhead, because every time you call a function you have some effort in pushing parameters onto the stack.

Solution 4

And another difference is that in function there is stack overhead but in case of macros there is no stack overhead; it is just the expansion of code.

View more solutions

Comments

[Almo]

Yeah, inline functions are better for this aspect.

[Zhenny]

If the function is inlined there will be no stack overhead.

[John Kugelman]

This answer is awfully muddled. It confuses more than it enlightens.

[Leushenko]

@JohnKugelman Well, what's confusing about it? How can I make it clearer for you? It seems straightforward enough to me or I wouldn't have written it out that way, and it is technically correct which is more than can be said for some of the existing answers to this question. Yeah yeah sure it's an old question, didn't see that when I wrote this answer, sorry. It still contributes different material to the question. Answers that focus on compile-time/runtime or machine-code/text are wrong, they describe an implementation but are missing the point.

[John Kugelman]

(a) A function is not strictly an operation from values to values; that's a mathematical definition. Functions have side effects, they're not just mappings. And they needn't return a value. (b) Saying a macro is "an operation from code to code" is a confusing way of describing what a macro is. I'd explain macros in terms of textual substitution. (c) There is huge overlap between functions and function-like macros. It's really strange to claim that they do not overlap in purpose. One major use of macros is to forcefully inline code that would otherwise go in a function.

[Leushenko]

There is zero overlap in purpose between functions and function-like macros, and I stand by that. There is overlap in usage (obvious by the fact the question exists), but they do not do that same thing. A macro can never take 2 and 2 and produce 4, it can only take 2 and 2 and produce 2+2. This is the core difference. Absolutely everything else is incidental/an implementation detail/specific to C culture. On the contrary, suggesting any relationship between macros and inlining is an example of the kind of thing that muddies the water on this topic.

[Gamal Othman]

This is not an answer to the question!