What is the difference between MACRO and FUNCTION?

N

Newbie_sw2003

Where should I use them?

I am giving you my understandings. Please correct me if I am wrong:

MACRO:
e.g.:#define ref-name 99
The code is substituted by the MACRO ref-name. So no overhead.
Execution is faster. Where will it be stotred?(Is it in bss/stack/?)

FUNCTION:
There will be a overhead due to function arguments. (Aguments are
stored in the stack)

Where MACROs can not be used?
=========================
If the macro defination go like kind of x++ and y++. It's better to
use functions and avoid macros. Use typedef instead of macros (while
pointer declarations).

Where FUNCTIONs can be used?
========================
Anywhere. But RELATIVELY there will be a overhead and takes more CPU
cycles to execute the same. If it's a macro, just simple substitution.

Please throw some light on the above understandings of mine.
-Newbie
 
J

Joona I Palaste

Newbie_sw2003 said:
Where should I use them?
I am giving you my understandings. Please correct me if I am wrong:
MACRO:
e.g.:#define ref-name 99
The code is substituted by the MACRO ref-name. So no overhead.

Correct. The compiler is not even aware that there was a macro. All
it sees is the substituted value.
Execution is faster. Where will it be stotred?(Is it in bss/stack/?)

The C standard does not define "bss", "stack", or any other storage.
It could be carved in stone if the implementation so wishes.
FUNCTION:
There will be a overhead due to function arguments. (Aguments are
stored in the stack)

There will also be overhead because of the function itself. Calling
a function is an operation that takes up time. Again, no specific
storage is defined by the standard.
Where MACROs can not be used?
=========================
If the macro defination go like kind of x++ and y++. It's better to
use functions and avoid macros. Use typedef instead of macros (while
pointer declarations).

Macros can't be pointed to either. You can give functions as
parameters to other functions, but not macros.
Also, macros can do things typedefs can't.
Where FUNCTIONs can be used?
========================
Anywhere. But RELATIVELY there will be a overhead and takes more CPU
cycles to execute the same. If it's a macro, just simple substitution.

Functions also have their own variable scope, so they have their own
local variables. Functions also have a proper notion of arguments, while
macros only use textual substitution.
Please throw some light on the above understandings of mine.
-Newbie

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Life without ostriches is like coffee with milk."
- Mika P. Nieminen
 
T

Tom Zych

Joona said:
The C standard does not define "bss", "stack", or any other storage.
It could be carved in stone if the implementation so wishes.

Who know, maybe nanocomputers will someday store data by removing
atoms of silicon from a surface...
 
D

Dan Pop

In said:
???

The compiler is not even aware that there was a macro.

For the simple reason that there was no macro at all.
All it sees is the substituted value.

No macro, no substitution. Only a syntax error requiring a diagnostic.

Dan
 
J

Joona I Palaste

For the simple reason that there was no macro at all.
No macro, no substitution. Only a syntax error requiring a diagnostic.

There I was, looking for some sense in Dan's reply, when it struck me.
The hyphen (-) is an illegal character in macro names, therefore Dan, in
his usual cryptic form, is right. The code would have to read:
#define ref_name 99

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"No, Maggie, not Aztec, Olmec! Ol-mec!"
- Lisa Simpson
 
D

Dan Pop

In said:
There I was, looking for some sense in Dan's reply, when it struck me.
The hyphen (-) is an illegal character in macro names, therefore Dan, in
his usual cryptic form, is right. The code would have to read:
#define ref_name 99

The harder you work to find a mistake, the less is the likelihood of ever
repeating it ;-)

Dan
 
E

Ed Morton

Correct. The compiler is not even aware that there was a macro. All
it sees is the substituted value.




The C standard does not define "bss", "stack", or any other storage.
It could be carved in stone if the implementation so wishes.

If "it" is the macro definition (as opposed to the invocation), it isn't stored.
The preprocessor expands the macro definition in-line so to the compiler it's
just more text within the function or wherever you happen to have placed the
macro invocation.
There will also be overhead because of the function itself. Calling
a function is an operation that takes up time. Again, no specific
storage is defined by the standard.




Macros can't be pointed to either. You can give functions as
parameters to other functions, but not macros.
Also, macros can do things typedefs can't.




Functions also have their own variable scope, so they have their own
local variables. Functions also have a proper notion of arguments, while
macros only use textual substitution.

I know you know this, but for the OP: macros CAN have their own scope too, if
you define them as such, e.g.:

#define PRTHELLO() do { \
char *_x = "hello"; \
puts(_x); \
} while (0)

Notes:

1) The underscore in front of the variable name - since macros are expanded
in-line, it's good to have a naming convention for variables declared within the
macro that at least attempts to separate them from the variables declared in a
calling function.

2) The backslashes at the end of each line - unlike a function, a macro
definition ends at the end of the line, so to let you split your text over
multiple lines for ease of reading, you need to escape the end of lines.

3) The { ... } - this creates the scope for local variable declarations AND
bug-proofs the code so that if someone wrote a multi-statement macro and then
put it inside an "if" with no braces, the whole body would be considered as one
block. e.g. if I define 2 macros:

#define DOAB() \
a(); \
b()

#define DOXY() { \
x(); \
y(); \
}

if (condition1)
DOAB();

if (condition2)
DOXY();

then this will expand to:

if (condition1)
a();
b(); /* NOTE: b() is no longer within the "if"
* and so will be executed unconditionally!
*/

if (condition2)
{
x();
y();
};

so if condition1 is fales, b() will still get executed.

4) The do ... while(0) - this forces callers of the macro to put a semi-colon at
the end. In the example above I had

if (condition2)
DOXYZ();

but that trailing semicolon is actually unnecessary as you can see from the
expanded version above and can in fact cause problems. By changing the
definition to:

#define DOXY() do { \
x(); \
y(); \
} while(0)

this expands to:

if (condition2)
do {
x();
y();
} while(0);

which does now require that trailing semi-colon. One advantage of requiring the
semicolon on the invocation is that you could in future replace the text in the
macro definition with a function call and not have to worry about potentially
introducing errors in the code of callers who had/hadn't been relying on not
needing that semicolon. For more info on "do ... while(0)", see the comp.lang.c
FAQ http://www.eskimo.com/~scs/C-faq/q10.4.html

5) The macro name is all upper-case - that's a pretty normal convention for
user-defined macros whereas function names are typically a mix of upper/lower case

6) Macros should be kept small - a rough rule of thumb for macros vs functions
is to only use macros if the code size is small (less than, say, 20 or so lines)
and you can't afford the function call real-time overhead.

Ed.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top