Is it better to use a macro or a function?

[madhawi]

Is it better to use a macro or a function?

 

[Ben Pfaff]

Is it better to use a macro or a function?

Some tasks can only be accomplished with a macro. Otherwise, use
a function: in general, they're safer.

 

[Tor Rustad]

Is it better to use a macro or a function?

There are a number of things that can go wrong with function-like macros,
see C FAQ Question 10.1

so use a function, whenever you can.

 

[Tejas Kokje]

Is it better to use a macro or a function?

If functions are relatively short, using a macro is better since it
avoids overhead of stack frame allocation ( saving stack pointer of
caller,saving return address of the instruction in caller function on
the stack frame etc).

However if the functions are long, using macros can be debugging nightmare.

Tejas Kokje

 

[Kenneth Brody]

Is it better to use a macro or a function?

Yes.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Richard Tobin]

Is it better to use a macro or a function?

As others have said, functions are cleaner where they work. Now that
support for inline functions is widespread, another large category of
cases can be done with functions.

-- Richard

 

[Richard Tobin]

Is it better to use a macro or a function?

[/QUOTE]

Is it better to use a spoon or a saw?

Where both are equally effective, obviously it is better to use a spoon.

-- Richard

 

[Chris Dollin]

If functions are relatively short, using a macro is better since it
avoids overhead of stack frame allocation ( saving stack pointer of
caller,saving return address of the instruction in caller function on
the stack frame etc).

If the functions are relatively short, calling them may well not
involve any stack frame allocation /at all/. The overhead may be
roughly two instructions -- call & return. Or, of course, the compiler
may inline the function completely.

Conclusion: if you want function-like semantics, use functions.

If you want to optimise for speed, for heaven's sake /measure
first/. (Actually, if you want to optimise for anything, measure
first.)

 

[Flash Gordon]

Tejas Kokje wrote, On 06/06/07 20:28:

If functions are relatively short, using a macro is better since it
avoids overhead of stack frame allocation ( saving stack pointer of
caller,saving return address of the instruction in caller function on
the stack frame etc).

Apart from when it does not. I'm sure it's over 10 years since I read a
compiler manual which talked about it inlining small functions.

1st rule of optimisation, don't do it. Whilst you think using a macro is
for a small function is better due to efficiency you are not ready for
the 2nd rule.

However if the functions are long, using macros can be debugging nightmare.

The same applies to small functions.

 

[Eric Sosman]

Is it better to use a macro or a function?

Is it better to use a spoon or a saw?

 

[Chris Dollin]

Is it better to use a spoon or a saw?

Where both are equally effective, obviously it is better to use a spoon.[/QUOTE]

"There is no spoon".

 

[Tejas Kokje]

If the functions are relatively short, calling them may well not
involve any stack frame allocation /at all/. The overhead may be
roughly two instructions -- call & return. Or, of course, the compiler
may inline the function completely.

I didn't get your first comment. If you don't allocate stack frame,
where are you going to store return address when you do "call & return" ?

Compiler *may* inline the function. But it is not obligated to do so.

Tejas Kokje

 

[Tejas Kokje]

Tejas Kokje wrote, On 06/06/07 20:28:

Apart from when it does not. I'm sure it's over 10 years since I read a
compiler manual which talked about it inlining small functions.

Are there any set of rules (even for a specific compiler) which says
that small functions with x,y,z properties will always be inlined ? It
would be interesting to know those

1st rule of optimisation, don't do it. Whilst you think using a macro is
for a small function is better due to efficiency you are not ready for
the 2nd rule.


The same applies to small functions.

With functions you have symbols in symbol table and you can use symbolic
debugger to debug problems.

However, with long macro functions, you don't have symbols in symbol table.

Hence for long functions, I would "prefer the compiler to the
preprocessor" [Scot Myers, Effective C++].

Tejas Kokje

 

[Chris Dollin]

I didn't get your first comment. If you don't allocate stack frame,
where are you going to store return address when you do "call & return" ?

In the specific case I am thinking of, in the return address register,
R14, which is where the call instruction puts it.

Compiler *may* inline the function. But it is not obligated to do so.

Of course. But the compiler is not obliged to generate efficient
code for /anything/. What makes compilers generate efficient code
is selection pressure from the users of those compilers; and that
selection pressure includes "inline calls when it makes sense to
do so".

When one wants function-like things, the natural things to use are
functions. Macros (as you know, Bob) have a pleasant selection of
gotchas to choose from, so are, IMAO, best avoided as function
substitutes /unless/ you have actual good reasons otherwise -- like
a real performance problem that they fix.

 

[Ian Collins]

Are there any set of rules (even for a specific compiler) which says
that small functions with x,y,z properties will always be inlined ? It
would be interesting to know those

The rules used to select functions for inline are documented with your
compiler. Most compilers I have used have options to tweak those rules
so you can balance performance and code size.

As a general rule (based on the compilers I have used), if a function
fits your criteria for a function like macro, it will fit the compiler's
criteria for an inline function.

 

[Flash Gordon]

Tejas Kokje wrote, On 06/06/07 22:42:

I didn't get your first comment. If you don't allocate stack frame,
where are you going to store return address when you do "call & return" ?

In the register or other space specifically designed for storing it.

Compiler *may* inline the function. But it is not obligated to do so.

Inlining the code can lead to a slower program because sometimes
increasing the size of the executable means more cache misses. The
optimiser is far more likely to judge this correctly than you especially
as you seem to be assuming inlining will always speed things up.

 

[Flash Gordon]

Tejas Kokje wrote, On 06/06/07 22:50:

Are there any set of rules (even for a specific compiler) which says
that small functions with x,y,z properties will always be inlined ? It
would be interesting to know those

Yes, in the manual I read over 10 years ago! If you want a more recent
example, read the documentation for gcc.

1st rule of optimisation, don't do it. Whilst you think using a macro
is for a small function is better due to efficiency you are not ready
for the 2nd rule.


The same applies to small functions.

With functions you have symbols in symbol table and you can use symbolic
debugger to debug problems.

However, with long macro functions, you don't have symbols in symbol table.

Hence for long functions, I would "prefer the compiler to the
preprocessor" [Scot Myers, Effective C++].

I was not sufficiently clear. I meant replacing small functions with
macros can also make debugging a nightmare and therefore it should not
be done unless there is a specific reason in that particular case (e.g.
you have measured, found you have a problem, and found that changing to
using a macro will actually speed things up significantly).

 

[Tejas Kokje]

In the specific case I am thinking of, in the return address register,
R14, which is where the call instruction puts it.

I may be going off topic, but which architecture has R14 register ? Is
it a general purpose register ? I don't think it is IA32.

Tejas Kokje

 

[Mark McIntyre]

I didn't get your first comment. If you don't allocate stack frame,
where are you going to store return address when you do "call & return" ?

Registers.
This is a very common optimisation.

Compiler *may* inline the function. But it is not obligated to do so.

Sure, but you agree that an inline function would not have a
stackframe.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

I may be going off topic, but which architecture has R14 register ?

www.google.com will tell you in about 0.11 seconds.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan