The difference in these 2 snippets of code

Question

Here are 2 snippets of code, one is a macro and one is a function. They seem to do the same thing but after running them it seems that they exhibit different behavior and I don't know why. Could anyone help me please? Thanks!

#define ROL(a, offset) ((((Lane)a) << ((offset) % LANE_BIT_SIZE)) ^ (((Lane)a) >> (LANE_BIT_SIZE-((offset) % LANE_BIT_SIZE))))

Lane rotateLeft(Lane lane, int rotateCount)
{
    return ((Lane)lane << (rotateCount % LANE_BIT_SIZE)) ^ ((Lane)lane >> (LANE_BIT_SIZE - (rotateCount % LANE_BIT_SIZE))) ;
}

Note: the Lane type is just an unsigned int and LANE_BIT_SIZE is a number representing the size of Lane in terms of No. of bits.

In what way do they exhibit different behavior? How are you invoking them and what difference do you see? — David Schwartz, Mar 04 '13 at 04:12

score 0 · Accepted Answer · answered Mar 04 '13 at 05:22

Think of using a macro as substituting the body of the macro into the place you're using it.

As an example, suppose you were to define a macro: #define quadruple(a) ((a) * (a) * (a) * (a))

... then you were to use that macro like so:

int main(void) {
    int x = 1;
    printf("%d\n", quadruple(x++));
}

What would you expect to happen here? Substituting the macro into the code results in:

int main(void) {
    int x = 1;
    printf("%d\n", ((x++) * (x++) * (x++) * (x++)));
}

As it turns out, this code uses undefined behaviour because it modifies x multiple times in the same expression. That's no good! Do you suppose this could account for your difference in behaviour?

score 0 · Answer 2 · answered Mar 04 '13 at 06:30

one is macro and other one is function, the simple understanding gives difference in the way it will be called.

As in case of function CONTEXT SWITCHING will be there, you code flow will be changed to the calling function and will return eventually so there will be very small delay in execution when compared to MACRO.

other than that there should not be any other difference.

Please try by declaring the function as inline function then both should be same.

score 0 · Answer 3 · answered Mar 04 '13 at 06:45

Lane may be promoted to a type with more bits, e.g. when it's an unsigned char or unsigned short, or when it is used in a larger assignment with mixed types. The <<operation will then shift the higher bits into the additional bits of the larger type.

With the function call these bits will be just cut off, because it returns a Lane, while the macro gives you the full result of the promoted type, including the additional bits - beside the other problems of macros, like multiple evaluations of the arguments.

Barath Ravikumar · Answer 4 · 2013-03-04T05:25:32.147

-2

Here are 2 snippets of code, one is a macro and one is a function. They seem to do the same thing but after running them it seems that they exhibit different behavior and I don't know why.

No they are doing the same thing.

ROL(a, offset);                          //does a*(2^offset)
rotateLeft(Lane lane, int rotateCount);  //does lane*(2^rotateCount)

The only difference is that ROL is implemented through a macro , and rotateLeft() is a function.

Differences between Macros and functions

Macros are executed in the preprocessing stage of the compiler , whereas function executes , when it is called at runtime execution.
As a result Macros execute faster than functions , but when called multiple times , the macro text is substitutes same code redundantly, and they end up consuming more "code" memory than an implementation using functions.
Unlike a function , there is no Type Enforcement in a macro.

edited Mar 04 '13 at 05:25

answered Mar 04 '13 at 04:29

Barath Ravikumar

5,658
3
23
39

1

"... Macros execute faster than functions, but when called multiple times they end up consuming more memory than functions."? Which C standard are you reading? – autistic Mar 04 '13 at 05:15
@modifiablelvalue , Thanks for the Correction there , i mean multiple inclusions of macros results in repeated text substitution , will , increase the code size , resulting in additional code segment memory space reqiurement. – Barath Ravikumar Mar 04 '13 at 05:23
Which section of the C standard states that? Suppose a dynamic finite state machine were used to convert C source files to behaviour (an "interpreter", if you will), and `#define` resulted in new rules being added to that state machine. There would be no text substitution there. – autistic Mar 04 '13 at 05:27
@modifiablelvalue why don't you correct the disadvantages under the third answer here http://stackoverflow.com/questions/4990362/what-is-the-difference-between-a-macro-and-a-function-in-c – Barath Ravikumar Mar 04 '13 at 05:29
Indeed. I should point out that the C standard doesn't mention a "stack", and that a "tree" would be more suitable given the nature of additions in 2011. – autistic Mar 04 '13 at 05:32
@modifiablelvalue i quote "Function consumes less memory. While a function replete with macros may look succinct on surface, prior to compilation, all the macro-presences are replaced by their corresponding macro expansions, which consumes considerable memory. On the other hand, even if a function is invoked 100 times, it still occupies the same space. Hence function is more amenable to less memory requirements. " from the website http://wiki.answers.com/Q/What_is_the_difference_between_a_macro_and_a_function – Barath Ravikumar Mar 04 '13 at 05:33
As has been answered elsewhere, another effect of a macro is that an argument with side-effects may end up being evaluated multiple times, depending on how many times it gets substituted in. – DoxyLover Mar 04 '13 at 05:34
That site contradicts itself. Consider if a sequence of macro substitutions is unable to fit into a CPU code cache line, while the series of equivalent function calls can. Which will run without cache misses? Which is more likely to perform more optimally? – autistic Mar 04 '13 at 05:38
... and that'll learn you for quoting sites that aren't the C standard. – autistic Mar 04 '13 at 05:39
You have given me -2 ,without letting me explain my part of the story, and i thank you for that , but as per rules lets stop and not convert this post into a chat room. – Barath Ravikumar Mar 04 '13 at 05:41
@modifiablelvalue I quote "However, after you have invoked the macro a few dozen times, it probably dawns on you that you are chewing up memory un-necessarily and that you can save a lot by changing the macro to this:" from http://embeddedgurus.com/stack-overflow/category/minimizing-memory-consumption/ .So evem a post from a well established site is wrong too ?? .Maybe you will blame the entire internet , defending your wrong statement ? Yes you argue on and on , but i'll stick to the rules and stop right here. – Barath Ravikumar Mar 04 '13 at 05:47
FWIW, I gave you -1 for answering the question incorrectly, and for attributing speed to language rather than implementation. – autistic Mar 04 '13 at 05:53
You're also attributing size to language. When considering that a C compiler might perform optimisations, isn't it reasonable to suggest that equivalent programs could be transformed to the same machine code? – autistic Mar 04 '13 at 05:56
@modifiablelvalue But your first comment suggested otherwise !! After quoting macros and memory from nigel jones an established Embedded engineer , whose experience far trumps your ignorance , you still dare to say "I gave you -1 for answering the question incorrectly" ?? One more comment , and i shall have you reported to the mods – Barath Ravikumar Mar 04 '13 at 05:56
Yes a 20yr experienced engineer is wrong and you are right , best of luck buddy , have a nice day :) – Barath Ravikumar Mar 04 '13 at 06:20

The difference in these 2 snippets of code

4 Answers4