函数调用作为其他函数的参数

Question

(I didn't know the correct terminology for this in order to do a search or give an appropriate title)

I have always wondered: does it matter (speedwise or compiled sizewise) if one uses a function call to provide the argument to another function? I can see how not doing that can aid code readability but sometimes using a bunch of local variables gets tedious.

What I mean: assuming these are called many times (as in a for..loop ) is there any practical difference between this:

      byte patternType = mCols[i].getPatternType();
      byte stepIndex = mCols[i].update(m);
      byte patternValue = getPatternValue(patternType, stepIndex);

and this:

      byte patternValue = getPatternValue(mCols[i].getPatternType(), mCols[i].update(m));

Answer 1

The order in which the parameters are evaluated is undefined. If the functions are pure, this should not matter, but if they have side-effects, it could.

Answer 2

It doesn't really matter. If you compile with optimizations turned on, the compiler should emit the same code in both cases; but the former has the advantage that it's easier to debug with optimizaton turned off.

I just tried this on my raspberry pi, as i don't have an arduino at hand.

This is my y1.c:

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

typedef signed char byte;

struct something {
    byte (*getPatternType)();
    byte (*update)(int i);
};

int main(void) {
    struct something mCols[20];
    int i;
    int m=3;

    for (i=0; i<20; i++) {
            byte patternType=mCols[i].getPatternType();
            byte stepIndex=mCols[i].update(m);
            byte patternValue=getPatternValue(patternType, stepIndex);
            printf("%d\n", patternValue);
    }
    exit(0);
}

and this is y2.c:

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

typedef signed char byte;

struct something {
    byte (*getPatternType)();
    byte (*update)(int i);
};

int main(void) {
    struct something mCols[20];
    int i;
    int m=3;

    for (i=0; i<20; i++) {
            byte patternValue=getPatternValue(mCols[i].getPatternType(), mCols[i].update(m));
            printf("%d\n", patternValue);
    }
    exit(0);
}

Then:

pi@pi$ cc -O4 -S y1.c
pi@pi$ cc -O4 -S y2.c
pi@pi$ diff y1.s y2.s
13c13
<       .file   "y1.c"
---
>       .file   "y2.c"

As you see, on assembler level, the only difference is the embedded source file name.

I added a printf so the compiler wouldn't just optimize out everything. It didn't, this is y1.s:

    .arch armv6
    .eabi_attribute 27, 3
    .eabi_attribute 28, 1
    .fpu vfp
    .eabi_attribute 20, 1
    .eabi_attribute 21, 1
    .eabi_attribute 23, 3
    .eabi_attribute 24, 1
    .eabi_attribute 25, 1
    .eabi_attribute 26, 2
    .eabi_attribute 30, 2
    .eabi_attribute 18, 4
    .file   "y1.c"
    .section        .text.startup,"ax",%progbits
    .align  2
    .global main
    .type   main, %function
main:
    @ args = 0, pretend = 0, frame = 160
    @ frame_needed = 0, uses_anonymous_args = 0
    stmfd   sp!, {r4, r5, r6, lr}
    mov     r4, #0
    sub     sp, sp, #160
.L2:
    add     r5, sp, #0
    ldr     r3, [r5, r4]!
    blx     r3
    add     r4, r4, #8
    ldr     r3, [r5, #4]
    mov     r6, r0
    mov     r0, #3
    blx     r3
    mov     r1, r0
    mov     r0, r6
    bl      getPatternValue
    sxtb    r1, r0
    ldr     r0, .L5
    bl      printf
    cmp     r4, #160
    bne     .L2
    mov     r0, #0
    bl      exit
.L6:
    .align  2
.L5:
    .word   .LC0
    .size   main, .-main
    .section        .rodata.str1.4,"aMS",%progbits,1
    .align  2
.LC0:
    .ascii  "%d\012\000"
    .ident  "GCC: (Debian 4.6.3-14+rpi1) 4.6.3"
    .section        .note.GNU-stack,"",%progbits

Note how the compiler treats the loop: the controlling register r4 is incremented by the size of the structure (8), not by one, and compared to 160, not 20, at the end. This saves the multiplication that the array index normally needs, but there's no way for a debugger to get the "real" value of i within the loop.

Answer 3

General advice:

Focus on code clarity and readability, let compiler does its work and optimizes away unnecessary things. Don't try to outsmart your compiler, it will do better than the programmer most of the cases at code optimization.

Also, be careful of order of evaluation and sequence points as pat suggested. You generally don't need to be concerned about these things if you write the code clear enough, tough.