inline vs macro

J

junky_fellow

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

sam_cit

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/comp.lang.c++/browse_thread/thread/2817c5a40313a697/?hl=en#

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

jacob navia

(e-mail address removed) 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
}
 
S

Stephen Sprunk

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
 
F

Fred Kleinschmidt

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

Chris Torek

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);
...
}
 
K

Keith Thompson

jacob navia said:
(e-mail address removed) a écrit :

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

dcorbit

Richard said:
(e-mail address removed) said:



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

Richard Heathfield

(e-mail address removed) said:
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.

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

CBFalconer

.... snip ...

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.

AFAICS they are (not present). They only show up as examples of
defines.
 
D

dcorbit

Richard said:
(e-mail address removed) said:


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

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

unsigned foo = 1;
unsigned bar = 2;

unsigned biggest = MAX(++foo, ++bar);

It does not matter if they want the side effects or not. The side
effects cause a defect due to the nature of macros that prevents them
from being used safely.
That can be a good thing or a bad thing, depending on whether you want the
type safety.

Have you ever heard of the Arianne failure? Type safety.
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.

I would stop them from using gets().
I would remove function macros from the language.
Neither feature has any merit, considering that alternatives exist
which are superior in every way.
It's not for us to tell people what compilers to use.

It's not an order. It's advice.
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.

Right, that's C++ with the header defect. Lots of C compilers mimic
it, though.
 
J

jaysome

(e-mail address removed) said:


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

Why would you ever want side effects?
That can be a good thing or a bad thing, depending on whether you want the
type safety.

Why would you ever NOT want 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.
Possibly.

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.

I just looked, and neither of my two hard-copies of the Schildt book
nor my PDF version of the standard mention anything about macros named
"min" or "max" now. I'm sure no one other than me has touched the
books in the past few days; and the modification date of the PDF file
didn't even change. How could that be?

Happy Holidays
 
R

Richard Heathfield

(e-mail address removed) said:
#define MAX(a,b) ((a) > (b) ? (a) : (b))

unsigned foo = 1;
unsigned bar = 2;

unsigned biggest = MAX(++foo, ++bar);

It does not matter if they want the side effects or not. The side
effects cause a defect due to the nature of macros that prevents them
from being used safely.

So you're saying macros can't be used safely because you can pass them
stupid arguments? Well, by the same token, functions that take parameters
can't be used safely because it is possible to pass stupid arguments to
them.
Have you ever heard of the Arianne failure? Type safety.

Have you ever heard of the Therac-25 failure? One of the principal causes of
this failure was software re-use. So let's stop re-using software. Or
perhaps we can stop making sweeping generalisations instead.
I would stop them from using gets().

Sure. It has no safe use.
I would remove function macros from the language.

But these *do* have a safe use.

<snip>
 
I

Ian Collins

I would stop them from using gets().
I would remove function macros from the language.
Neither feature has any merit, considering that alternatives exist
which are superior in every way.
Function macros have one - access to __FILE__ and __LINE__ and ## for
error logging.
 
R

Richard Heathfield

jaysome said:
Why would you ever want side effects?

Here's an example of a side effect that you want:

int n = printf("Hello, world.\n");
This line sets n to 14. As a side-effect, it displays "Hello, world.\n" on
the standard output device. Side effects can be quite handy.
Why would you ever NOT want type safety?

Sometimes it gets in the way. That's why void * exists.

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.

I just looked, and neither of my two hard-copies of the Schildt book
nor my PDF version of the standard mention anything about macros named
"min" or "max" now. I'm sure no one other than me has touched the
books in the past few days; and the modification date of the PDF file
didn't even change.

See? It worked!
How could that be?

Magic!
 
D

dcorbit

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

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <float.h>

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

int main(void)
{
size_t a,
b,
c;
char *s0,
*s1,
*s2;
long long d = LLONG_MAX;
float g = FLT_MAX;
a = 1;
b = 2;
c = MAX(++b, ++a);
s0 = "My name is Skinner The Grinner.";
s1 = "I am a foo bird but I can't fly";
s2 = MAX(s1, s0);
a = MAX(d, g);
printf("here are my MAX things:c=%u,s2=%s,a=%.0f\n", (unsigned)c,
s2, (double) a);
return 0;
}
 
C

CBFalconer

Richard said:
(e-mail address removed) said:
.... snip ...
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.

Right, that's C++ with the header defect. Lots of C compilers
mimic it, though.

No, that's the C standard. Any ISO C standard, new or old. Just
thank Richard for satisfying your every wish. Ain't alternate
universes grand.
 
D

dcorbit

Richard said:
(e-mail address removed) said:


So you're saying macros can't be used safely because you can pass them
stupid arguments? Well, by the same token, functions that take parameters
can't be used safely because it is possible to pass stupid arguments to
them.

No. I am saying that you do not know if MAX(a,b) is a macro or a
function unless you examine the implementation.

MAX(++a,++b) is prefectly fine if it is a function and we do not know
if it is OK if it is a macro.

The arguments are stupid if it is a macro and not stupid if it is a
function. But you cannot tell which is which unless you see the actual
definition. In a ten million line C project, will you know for sure
which things are macros and which things are functions?
By their very nature, function macros are defective and cause defects.
Have you ever heard of the Therac-25 failure? One of the principal causes of
this failure was software re-use. So let's stop re-using software. Or
perhaps we can stop making sweeping generalisations instead.

Reusing bad software is worse than not reusing it.
Sure. It has no safe use.

Wrong. It is used safely when you never input more bytes than the size
of the object.
In a similar way, function macros are fatally flawed. They can be used
safely, but normal use is not safe.
But these *do* have a safe use.

Just like gets() -- only with extreme care.
 
J

jaysome

jaysome said:

Here's an example of a side effect that you want:

int n = printf("Hello, world.\n");
This line sets n to 14. As a side-effect, it displays "Hello, world.\n" on
the standard output device. Side effects can be quite handy.

Of course.

What I meant was: "Why would you ever want side effects in macros?".

Your example could easily be extended, to help answer that question.

#define SQUARED(x) (int)((x)*(x))
int k = SQUARED(printf("Hello, world.\n"));

But, what I suspect that Dann meant, was: "Lack of *undesired* side
effects due to multiple evaluation"; something like this:

#define ABS(x) ((x) < 0 ? -(x) : (x))
... ABS( n++ )
Sometimes it gets in the way. That's why void * exists.

But the standard uses void * safely, doesn't it? Look at malloc()'s
prototype in <stdlib.h>.

Of course, if you use malloc(), then you better:

1. Include the header file <stdlib.h>.
2. Not cast its return value.
3. Check for a return value of NULL.

Barring any undefined behavior, use of void * seems type safe to me.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top