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.