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.:#defin e 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
