Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C Programming Language

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?

Some tasks can only be accomplished with a macro.  Otherwise, use
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?

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

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

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

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

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

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

"There is no 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.

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

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

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

Tejas Kokje

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.

--
Other Reasons Exist Hedgehog
"I just wonder when we're going to have to sit down and re-evaluate
 our decision-making paradigm." /Sahara/

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.

--
Ian Collins.

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

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.

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

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

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.

Which ones for x86 architecture ? Also what if you want to pass
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.

I don't know how inline functions are implemented by compilers. But I
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:

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

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).
--
Flash Gordon
Tejas Kokje wrote, On 06/06/07 22:42:

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

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

But I saw a 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.

Ok, I'll bite. Why is a function safer than a function-like macro?

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