|
|
 |
 |
 |
 |
Is it better to use a macro or a function?
Is it better to use a macro or a function?
Is it better to use a macro or a function?
madhawi <madhaw @gmail.com> writes: > Is it better to use a macro or a function?
a function: in general, they're safer.
--
Ben Pfaff
http://benpfaff.org
madhawi wrote:
> Is it better to use a macro or a function?
Sometimes.
--
Evil Hedgehog
"I just wonder when we're going to have to sit down and re-evaluate
our decision-making paradigm." /Sahara/
madhawi wrote:
> 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.
--
Tor <torust [at] online [dot] no>
madhawi wrote:
> 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
madhawi wrote: > Is it better to use a macro or a function?
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamT@gmail.com>
Tejas Kokje wrote: > madhawi wrote: >> 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).
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.)
--
Measured But Unoptimised Hedgehog
"Based on their behaviour so far -- I have no idea" /Sahara/
madhawi wrote:
> Is it better to use a macro or a function?
Is it better to use a spoon or a saw?
--
Eric Sosman
esos@acm-dot-org.invalid
In article <1181150311.126402.29@i13g2000prf.googlegroups.com>,
madhawi <madhaw @gmail.com> wrote: >Is it better to use a macro or a function?
support for inline functions is widespread, another large category of
cases can be done with functions.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
In article <keWdnUK-UI-wg_rbnZ2dnUVZ_gmdn@comcast.com>,
Eric Sosman <esos@acm-dot-org.invalid> wrote:
>> Is it better to use a macro or a function?
> Is it better to use a spoon or a saw?
Where both are equally effective, obviously it is better to use a spoon.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Tejas Kokje wrote, On 06/06/07 20:28:
> madhawi wrote: >> 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).
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.
--
Flash Gordon
Richard Tobin wrote: > In article <keWdnUK-UI-wg_rbnZ2dnUVZ_gmdn @comcast.com>, > Eric Sosman <esos @acm-dot-org.invalid> wrote: >>> Is it better to use a macro or a function?
>> Is it better to use a spoon or a saw?
> Where both are equally effective, obviously it is better to use a spoon.
--
It's Not A Trilogy, There Can Be Only One Hedgehog
A rock is not a fact. A rock is a rock.
Chris Dollin wrote: > Tejas Kokje wrote: >> madhawi wrote:
>>> 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).
> 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.
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
Flash Gordon wrote: > Tejas Kokje wrote, On 06/06/07 20:28: >> madhawi wrote: >>> 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).
> 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.
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.
>> However if the functions are long, using macros can be debugging
>> nightmare.
> The same applies to small functions.
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
Tejas Kokje wrote: > Chris Dollin wrote: >> Tejas Kokje wrote: >>> madhawi wrote:
>>>> 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).
>> 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" ?
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.
--
Other Reasons Exist Hedgehog
"I just wonder when we're going to have to sit down and re-evaluate
our decision-making paradigm." /Sahara/
Tejas Kokje wrote: > Flash Gordon wrote: >> Tejas Kokje wrote, On 06/06/07 20:28: >>> madhawi wrote: >>>> 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).
>> 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
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.
--
Ian Collins.
Chris Dollin wrote: > Tejas Kokje wrote: >> Chris Dollin wrote:
>>> Tejas Kokje wrote:
>>>> madhawi wrote:
>>>>> 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).
>>> 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" ?
> In the specific case I am thinking of, in the return address register,
> R14, which is where the call instruction puts it.
it a general purpose register ? I don't think it is IA32.
Tejas Kokje
>> 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.
On Wed, 06 Jun 2007 14:42:40 -0700, in comp.lang.c , Tejas Kokje
<binarysemaph @gmail.com> wrote: >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" ?
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
On Wed, 06 Jun 2007 15:29:41 -0700, in comp.lang.c , Tejas Kokje
<binarysemaph @gmail.com> wrote: >I may be going off topic, but which architecture has R14 register ?
--
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 wrote: > On Wed, 06 Jun 2007 14:42:40 -0700, in comp.lang.c , Tejas Kokje > <binarysemaph @gmail.com> wrote: >> 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.
arguments ? Will they be stored in registers as well ?
>> 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.
would be surprised if compiler inlined a function without me telling it
to do so (-O, -O2 etc for gcc).
Tejas Kokje
Tejas Kokje wrote, On 06/06/07 22:50:
> Flash Gordon wrote: >> Tejas Kokje wrote, On 06/06/07 20:28: >>> madhawi wrote: >>>> 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).
>> 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
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. >>> However if the functions are long, using macros can be debugging
>>> nightmare.
>> 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++].
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).
--
Flash Gordon
Tejas Kokje wrote, On 06/06/07 22:42:
> Chris Dollin wrote: >> Tejas Kokje wrote: >>> madhawi wrote:
>>>> 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).
>> 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.
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
Chris Dollin <e @electrichedgehog.net> writes: > Richard Tobin wrote: >> In article <keWdnUK-UI-wg_rbnZ2dnUVZ_gmdn@comcast.com>,
>> Eric Sosman <esos@acm-dot-org.invalid> wrote:
>>>> Is it better to use a macro or a function?
>>> Is it better to use a spoon or a saw?
>> Where both are equally effective, obviously it is better to use a spoon.
> "There is no spoon".
--
Keith Thompson (The_Other_Keith) k@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Ben Pfaff wrote: > madhawi <madhaw @gmail.com> writes: >> 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.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
|
 |
 |
 |
 |
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc