Why prefer start + (end - start) / 2 over (start + end) / 2 when calculating the middle of an array?

后端 未结 4 1588
时光说笑
时光说笑 2020-11-29 17:02

I\'ve seen programmers use the formula

mid = start + (end - start) / 2

instead of using the simpler formula

mid = (start +          


        
4条回答
  •  夕颜
    夕颜 (楼主)
    2020-11-29 17:41

    There are three reasons.

    First of all, start + (end - start) / 2 works even if you are using pointers, as long as end - start doesn't overflow1.

    int *start = ..., *end = ...;
    int *mid = start + (end - start) / 2; // works as expected
    int *mid = (start + end) / 2;         // type error, won't compile
    

    Second of all, start + (end - start) / 2 won't overflow if start and end are large positive numbers. With signed operands, overflow is undefined:

    int start = 0x7ffffffe, end = 0x7fffffff;
    int mid = start + (end - start) / 2; // works as expected
    int mid = (start + end) / 2;         // overflow... undefined
    

    (Note that end - start may overflow, but only if start < 0 or end < 0.)

    Or with unsigned arithmetic, overflow is defined but gives you the wrong answer. However, for unsigned operands, start + (end - start) / 2 will never overflow as long as end >= start.

    unsigned start = 0xfffffffeu, end = 0xffffffffu;
    unsigned mid = start + (end - start) / 2; // works as expected
    unsigned mid = (start + end) / 2;         // mid = 0x7ffffffe
    

    Finally, you often want to round towards the start element.

    int start = -3, end = 0;
    int mid = start + (end - start) / 2; // -2, closer to start
    int mid = (start + end) / 2;         // -1, surprise!
    

    Footnotes

    1 According to the C standard, if the result of pointer subtraction is not representable as a ptrdiff_t, then the behavior is undefined. However, in practice, this requires allocating a char array using at least half the entire address space.

提交回复
热议问题