By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,558 Members | 1,399 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,558 IT Pros & Developers. It's quick & easy.

What is the difference between MACRO and FUNCTION?

P: n/a
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
Nov 13 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Newbie_sw2003 <ne***********@yahoo.com> scribbled the following:
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 (pa*****@cc.helsinki.fi) ---------------------------\
| 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
Nov 13 '05 #2

P: n/a
Joona I Palaste wrote:
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...

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #3

P: n/a
In <bj**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Newbie_sw2003 <ne***********@yahoo.com> scribbled the following:
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.
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #4

P: n/a
Dan Pop <Da*****@cern.ch> scribbled the following:
In <bj**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Newbie_sw2003 <ne***********@yahoo.com> scribbled the following:
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. 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.


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 (pa*****@cc.helsinki.fi) ---------------------------\
| 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
Nov 13 '05 #5

P: n/a
Newbie_sw2003 wrote:
e.g.:#define ref-name 99


'-' is not a legal character for C identifiers. Just A-Z a-z 0-9 and
'_'.

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #6

P: n/a
In <bj**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Dan Pop <Da*****@cern.ch> scribbled the following:
In <bj**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Newbie_sw2003 <ne***********@yahoo.com> scribbled the following:
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.
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.


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #7

P: n/a


On 9/10/2003 6:05 AM, Joona I Palaste wrote:
Newbie_sw2003 <ne***********@yahoo.com> scribbled the following:
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.


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.
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.


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.
Please throw some light on the above understandings of mine.
-Newbie



Nov 13 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.