«

hi guys,

Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa ? Is there any case where
using a macro will be more efficient as compared to inline function ?

thanks for any help in advance ...

wrote:
> hi guys,
>
> Can you please suggest that in what cases should a macro be
> preferred over inline function and viceversa ? Is there any case where
> using a macro will be more efficient as compared to inline function ?
>
> thanks for any help in advance ...

You could refer to the following link,

http://groups.google.co.in/group/com...13a697/?hl=en#

And inline functions are much better than Macro, which you will
understand if you look at the examples in the above thread.

a écrit :
> hi guys,
>
> Can you please suggest that in what cases should a macro be
> preferred over inline function and viceversa ? Is there any case where
> using a macro will be more efficient as compared to inline function ?
>
> thanks for any help in advance ...
>

#define max(a,b) ((a<b)?b:a)

Defining an inline function(s) for that would be
quite difficult...

The same for min(a,b)

Other "advantages" of macros is that they can capture
local variables in the calling function:

#define myhack(a) (a+sqrt(var))

void fn(double var)
{
int a;

...
myhack(a);
...
}

You see? The argument var is implicitely passed
to the macro.

On the other hand:

An advantage of inline functions is that they
do not capture local variables in the calling
function:

inline double myhack(int a)
{
return a+sqrt(var);
// This "var" refers to a global variable var,
// NOT to a local variable. This avoids
// UNINTENTIONAL problems with local
// variables
}

<> wrote in message
news: ps.com...
> Can you please suggest that in what cases should a macro be
> preferred over inline function and viceversa ?

An inline function has type safety and doesn't suffer from
double-evaluation problems.

A macro has type generic-ness and can modify its arguments.

Only one of them may meet your needs in particular cases, though in the
simplest examples they may both work equally well.

> Is there any case where using a macro will be more efficient as
> compared to inline function ?

If you can replace one with the other and preserve the caller's syntax,
there is no reason to expect one to be more efficient than the other. A
compiler should treat them the same.

Sometimes you can't replace a macro, though. Consider:

#define INC(x) (x++)

A function simply can't do the same thing. You'd have to change callers
from this:

int x=0;
INC(x);

to:

int x=0;
x = inc(x); /* assumes int inc(x) { return x+1; } */

You might also be calling the macro with varying type arguments; there
is no way to write an inline function to replace INC() above that can
handle both doubles and ints correctly.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking


--
Posted via a free Usenet account from http://www.teranews.com

<> wrote in message
news: ps.com...
> hi guys,
>
> Can you please suggest that in what cases should a macro be
> preferred over inline function and viceversa ? Is there any case where
> using a macro will be more efficient as compared to inline function ?
>
> thanks for any help in advance ...
>

#define MAXOF(x,y) ((x)>(y)?(x)y))

This macro can be used for short, int, long, float, double, or any
combination of them. To use a function would require
defining many separate functions.


--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project

said:

<snip>

> And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

In article < om>
<> wrote:
> Can you please suggest that in what cases should a macro be
>preferred over inline function and viceversa?

The advantage of a macro is that it simply performs textual
substitution.

The disadvantage of a macro is that it simply performs textual
substitution.

Besides the other examples posted so far, macros also have access
to the preprocessor's "#" and "##" operators:

#define DEBUG_INTEGER(var) fprintf(stderr, "DEBUG: " #var " = %d\n", var)
#define DEBUG_STRING(var) fprintf(stderr, "DEBUG: " #var " = %s\n", var)
void foo(void) {
int zorg, blaggle;
char *graump;
...
DEBUG_INTEGER(zorg);
DEBUG_INTEGER(blaggle);
DEBUG_STRING(graump);
...
}
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

jacob navia <> writes:
> a écrit :
>> hi guys,
>> Can you please suggest that in what cases should a macro be
>> preferred over inline function and viceversa ? Is there any case where
>> using a macro will be more efficient as compared to inline function ?
>> thanks for any help in advance ...
>>
>
> #define max(a,b) ((a<b)?b:a)
>
> Defining an inline function(s) for that would be
> quite difficult...
[...]

Surely you mean:

#define MAX(a, b) (((a) < (b)) ? (b) : (a))

(with an added comment warning that one of the arguments will be
evaluated twice).

One disadvantage of inline functions is that some compilers may not
support them, or may not support them correctly. Yes, they're defined
in C99, the One True Standard for the C programming language, but C99
is not universally implemented.

--
Keith Thompson (The_Other_Keith) kst- <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.

Richard Heathfield wrote:
> said:
>
> <snip>
>
> > And inline functions are much better than Macro
>
> Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation
Type safety
Less prone to undefined behavior

A function macro offers something for the lazy programmer:
A poor man's C++ template in C ... Make that a destitute man's C++
somewhat template like thingy in C. Except that they are universally
broken.

But the ability to apply that macro to any argument is one of its
largest downfalls.

In short, function macros are the result of hazardous laziness. There
is not one single instance where the correct functions would not be
superior. If your compiler does not support inline functions, it is
time to get a new compiler. If no compiler is available for your
toaster IC, then just write the code inline instead of using macros.
Because hey, who likes burnt toast in the morning.

If I had my way, min(a,b) and max(a,b) would be removed from the
standard library headers. They are not as bad as gets(), but still
completely awful.

> --
> Richard Heathfield
> "Usenet is a strange place" - dmr 29/7/1999
> http://www.cpax.org.uk
> email: rjh at the above domain, - www.

said:

>
> Richard Heathfield wrote:
>> said:
>>
>> <snip>
>>
>> > And inline functions are much better than Macro
>>
>> Why do you think so? And what do you mean by "better"?
>
> Superior in every way that I can imagine.
> Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want the
side effects.

> Type safety

That can be a good thing or a bad thing, depending on whether you want the
type safety.

> Less prone to undefined behavior

Perhaps. But if you stop people doing stupid things, it's generally at the
expense of stopping them doing clever things, too. Doug Gwyn once said
something of the kind.

<snip>

> If your compiler does not support inline functions, it is
> time to get a new compiler.

It's not for us to tell people what compilers to use.

> If I had my way, min(a,b) and max(a,b) would be removed from the
> standard library headers.

[F/X: waves magic wand] Since it is the season of gifts, Dann, your wish is
granted. Not only have I removed min and max from the standard library
headers for you, but I have applied this change retroactively, so that it
shall be as if they had *never* been part of the standard library headers.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.