Difference between a MACRO and a FUNCTION

[MAx]

Hi,
Could any one list possible number of diferences between a function
and a macro?
which one will be faster and why??

ex : function and a macro ti find max of two nums
#define MAX(a,b) (a>b) ? a:b

and
int max(int a,int b)

 

[Ian Collins]

Hi,
Could any one list possible number of diferences between a function
and a macro?
Homework?

which one will be faster and why??

The answer is either or neither.

 

[Mark Bluemel]

Hi,
Could any one list possible number of diferences between a function
and a macro?
which one will be faster and why??

Do I smell homework?

 

[MAx]

Do I smell homework?

obviously not a homework.
this was an interview question...
i am looking for an impressive answer.

 

[Mark Bluemel]

obviously not a homework.

There's no "obviously" about it...

this was an interview question...
i am looking for an impressive answer.

Then I suggest you do some research - other than asking in a newsgroup -
and produce one.

 

[MAx]

There's no "obviously" about it...


Then I suggest you do some research - other than asking in a newsgroup -
and produce one.

Thanks for the help

 

[Army1987]

Hi,
Could any one list possible number of diferences between a function
and a macro?
which one will be faster and why??

The macro will usually be faster, unless the compiler is smart
enough to inline the function call. Since C99 you can suggest the
compiler to do so by using the 'inline' keyword.

ex : function and a macro ti find max of two nums
#define MAX(a,b) (a>b) ? a:b

Please add enough parentheses:
((a) > (b) ? a : (b))
As you wrote it, using complicated expressions could yield the
wrong semantic due to the precedence (actually, syntax) rules.

Note that the one returned will have been evaluated twice, so be
careful not to pass it expression with side effects.

and
int max(int a,int b)

This one doesn't suffer the problems described above, but it will
be much slower than the macro unless the compiler inlines it, and
it always convert the arguments to int and return an int, where
the macro return the "correct" type depending on the type of the
arguments.

 

[Richard Heathfield]

Army1987 said:

On Thu, 20 Sep 2007 00:04:05 -0700, MAx wrote:


Please add enough parentheses:
((a) > (b) ? a : (b))

You missed some.

<snip>

 

[Philip Potter]

Army1987 said:

You missed some.

<snip>

Really?

(((a)>(b)) ? a : (b))

has the same meaning, as does

((a)>(b) ? (a) : (b))

Though this does look nicer due to consistency.

The only other places I can think to add parentheses are either redundant ((a))
or obviously wrong ((a) > ((b) ? a : (b)))

So what did he miss?

Phil

 

[Mark Bluemel]

Thanks for the help

You're welcome. I wasn't just being snitty (though that's probably part
of it).

This actually does, in effect, come under the "homework" heading. The
point of the exercise should be for you to learn something for yourself
by putting in the necessary effort, rather than being spoonfed something
which you can hand in to your tutor or spout to your interviewer.

 

[Army1987]

Army1987 said:

You missed some.

Syntax
1 conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression

(As someone pointed out on this newsgroup, ? and : can only occur
in pairs, so they are like [ and ], or ( and ) for this matter.)

 

[Richard Heathfield]

Philip Potter said:

Really?

No, not really - at least, I just tried three times to break his version
and failed each time. So I owe him an apology.

(((a)>(b)) ? a : (b))

has the same meaning, as does

((a)>(b) ? (a) : (b))

Though this does look nicer due to consistency.

Yes, it does, doesn't it? Emerson notwithstanding...

 

[Army1987]

Philip Potter said:

Army1987 said:
Please add enough parentheses:
((a) > (b) ? a : (b))
You missed some.

[snip]
(((a)>(b)) ? a : (b))

has the same meaning, as does

((a)>(b) ? (a) : (b))

Though this does look nicer due to consistency.

Yes, it does, doesn't it? Emerson notwithstanding...

It does (maybe whitespace around > will add even more
consistency?), but who's Emerson?

 

[Eberhard Schefold]

It does (maybe whitespace around > will add even more
consistency?), but who's Emerson?

"A foolish consistency is the hobgoblin of little minds."
-- Ralph Waldo Emerson (1803–1882)

Don't think I'm a literary person, but I remembered the line from
"What's Up, Doc".

 

[John Bode]

Hi,
Could any one list possible number of diferences between a function
and a macro?

Grab your handy C reference and read the section about the
preprocessor, focusing on the terms "definition" and "replacement".
After that, it should be quite obvious what the differences between a
function and a function-like macro are.

which one will be faster and why??

That depends on the operations involved. For your example below, all
things being equal, the macro should be faster. Again, once you've
read up on what exactly the preprocessor does with a function-like
macro definition, the reason why should be fairly evident.

 

[Keith Thompson]

Could any one list possible number of diferences between a function
and a macro?
which one will be faster and why??

ex : function and a macro ti find max of two nums
#define MAX(a,b) (a>b) ? a:b

and
int max(int a,int b)

Is this homework?

 

[Keith Thompson]

Philip Potter said:

No, not really - at least, I just tried three times to break his version
and failed each time. So I owe him an apology.

[...]

Nevertheless, I would certainly use parentheses myself:
#define MAX(a, b) ((a) > (b) ? (a) : (b))
rather than
#define MAX(a, b) ((a) > (b) ? a : (b))

Consistency is certainly part of it. Another part is that I'm *still*
not 100% convinced that the parentheses are unnecessary. I have a
nagging hunch that there *might* be an argument that would break the
first form, perhaps something involving the ?: operator in the operand
itself. Or perhaps there's some argument that should be a syntax
error, but that will cause the unparenthesized version to expand to a
legal expression that doesn't do what you want.

It's very likely that my concern is groundless, and that the
unparenthesized form is perfectly safe. But if it takes an
experienced C programmer like RH three tries, not to prove that it's
safe, but merely to fail to prove that it isn't, then it's likely to
waste some of the time of every attentive programmer who reads it. If
I'm tracking down a bug that manifests itself anywhere near any use of
this macro, I'm likely to waste time convincing myself that the macro
isn't the problem before persuing other possibilities.

We had something similar here recently, with a macro definition
something like:

#define N -42

Several people immediately complained that it *should* be

#define N (-42)

but it took a day or two before anyone was able to present an example
where it actually made a difference.

 

[Richard Heathfield]

Keith Thompson said:

I have a
nagging hunch that there *might* be an argument that would break the
first form, perhaps something involving the ?: operator in the operand
itself.

That was my principal method of attack. I couldn't break it that way, but
that doesn't mean it can't be broken. (Nor does it mean it can,
obviously.)

I suspect that a grammatical analysis will bear more fruit than any number
of attempts at a crack.

<snip>

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

Philip Potter said:

No, not really - at least, I just tried three times to break his
version and failed each time. So I owe him an apology.

[...]

Nevertheless, I would certainly use parentheses myself:
#define MAX(a, b) ((a) > (b) ? (a) : (b))
rather than
#define MAX(a, b) ((a) > (b) ? a : (b))

Consistency is certainly part of it. Another part is that I'm *still*
not 100% convinced that the parentheses are unnecessary. I have a
nagging hunch that there *might* be an argument that would break the
first form, perhaps something involving the ?: operator in the operand
itself.

The relevant rules from the grammar are:

primary-expression:
( expression )

conditional-expression:
logical-OR-expression ? expression : conditional-expression

Assuming a is an expression, it is valid in both forms. If it's not
valid, it's not an expression. Even if a contains a nested conditional
expression, for example in MAX(1 ? 2 : 3, 4 ? 5 : 6), the compiler will
do the right thing, since you're allowed to write an expression

((1 ? 2 : 3) > (4 ? 5 : 6) ? 1 ? 2 : 3 : (4 ? 5 : 6))

with no more a problem with the ?: nesting than with the () nesting.

Or perhaps there's some argument that should be a syntax error,
but that will cause the unparenthesized version to expand to a legal
expression that doesn't do what you want.

#define A 0)==(0

The parenthesised version will accept MAX(A, A), as it expands to

((0)==(0) > (0)==(0) ? (0)==(0) : (0)==(0))

while the unparenthesised version will show that this is a syntax error.
I don't consider this a good reason to not parenthesise a. Similarly, if
a similar construct is found that's valid with the second definition, but
not with the first, I don't consider it a good reason to include the
parentheses. (For what it's worth, I tried finding one, but failed to.)

Personally, I'd probably parenthesise a too, so that preprocessor output
is a little bit easier to read, and because I don't see a downside to it,
but it's not necessary.

 

[John Bode]

obviously not a homework.
this was an interview question...
i am looking for an impressive answer.

If you don't already have a good answer for that particular question
(or know where to look it up), then you shouldn't be interviewing for
a job that involves C programming.