[avr-gcc-list] Re: sprintf

[David Brown]

Joerg Wunsch wrote:
> David Brown <address@hidden> wrote:
>
> > Secondly, using pointer arithmetic when array access is the
> > logically correct method is very bad practice.
>
> That's often a matter of taste.  Once you grasped the C pointer
> semantics, I usually find
>
>         foo + i
>
> much easier to parse than
>
>         &foo[i].
>
> Both expressions are always equivalent.
>
> Of course,
>
>         *(foo + i)
>
> is terrible, because
>
>         foo[i]
>
> is much clearer then.
>
> Anyway, for the compiler, it should never make any difference, because
> these expressions are identical in their effect.  If the compiler can
> (statically) bounds-check &foo[i], I don't see why it would not be
> able doing so for foo + i.  (Most of the time, it cannot check it
> though.)

The two expressions (foo + i) and &foo[i] are *not* equivalent, because 
one is a pointer arithmetic expression and the other is taking the 
address of an element of an array.  They should boil down to the same 
calculations (the C standard says so).  However, the compiler has a much 
better chance of doing bounds checking, alias checking, and other 
optimisations on the array expression.  It is even free to reorganise 
the array, or keep it all in registers (I don't think any compilers do 
that, but maybe one day...), whereas working with raw addresses will 
often cause the compiler to lose the extra knowledge of the array. 
Recent improvements in gcc include keeping the array information further 
into the code generation process (rather than generating pointer 
arithmetic) for this reason, as far as I understand (I could be wrong 
here - you are the expert!).

Additionally, &foo[i] and (foo + i) read as different things (one is the 
address of an element, the other is the address of an array plus an 
offset).  To my mind, these are different and I'd use them in different 
types of code.

Finally, if you are using C++ rather than C, using array notation allows 
overloading to make types that work logically as arrays without 
necessarily being a contiguous block of memory.

mvh.,

David