Indizes statt Pointer

[void (Gast)]

Ich stelle fest, dass Pointer neben dem ggf. höheren Speicherbedarf (16 
bit statt z.B. ein 8 bit Index) auch durch die notwendige Arithmetik für 
den Zugriff auf Listen eigentlich keinen Vorteil bringen.

Wie sieht das der GCC?

[Volker Z. (vza)]

Bei einem eimaligem zugriff hast du recht. Wenn du öfters auf dein Array 
zugreifst ist die Pointer aretmetik sicherlich schneller, da weniger 
Rechenoperationen.
Desweiteren kommt es immer noch auf die Plattform an. (Brite von Daten 
und Adressen, seperate Adress-ALU, HW-Multipliziere, etc.)

Eine pauschale Aussage ist nicht möglich!

[Oliver (Gast)]

>Wie sieht das der GCC?

Für den gcc, wie für alle anderen C-Compiler auch, ist ein Pointer ein 
Pointer, und ein Index ein Index.

>16 bit statt z.B. ein 8 bit Index

Hmm. Und was ist bei mehr als 255 Listenelementen? Auf 
32-Bit-Architekturen? Bei dynamischen Listen?

Alles nicht so einfach...

Oliver

[void (Gast)]

Mhh, macht er nicht aus dem Index einen Pointer, wenn er den Index auf 
die Startadresse addiert?
Ist irgendwo dokumentiert, wie der GCC mit Arrays und ihren Indizes 
umspringt? Interessiert mich.

[Volker Z. (vza)]

In der Assemblerausgabe.
Mir fällt gerade der Compilerschalter nicht ein.

[(prx) A. K. (prx)]

Es kann durchaus passieren, dass der Compiler zur Schleifenoptimierung 
zusätzlich oder alternativ zum laufenden Index einen Pointer mitzieht.

[Karl H. (kbuchegg)]

void schrieb:
> Mhh, macht er nicht aus dem Index einen Pointer, wenn er den Index auf
> die Startadresse addiert?
> Ist irgendwo dokumentiert, wie der GCC mit Arrays und ihren Indizes
> umspringt? Interessiert mich.

Wahrscheinlich so, wie der C-Standard dies vorsieht.

Er behandelt

    a[i]

so, als ob du  *(a+i)  geschrieben hättest.

[Bernd O. (bitshifter)]

Karl heinz Buchegger schrieb:
> void schrieb:
>> Mhh, macht er nicht aus dem Index einen Pointer, wenn er den Index auf
>> die Startadresse addiert?
>> Ist irgendwo dokumentiert, wie der GCC mit Arrays und ihren Indizes
>> umspringt? Interessiert mich.
>
> Wahrscheinlich so, wie der C-Standard dies vorsieht.
>
> Er behandelt
>
>     a[i]
>
> so, als ob du  *(a+i)  geschrieben hättest.
War's nicht eher *(a+(i*sizeof(a[0])))

Gruß,
Bernd

[Thomas P. (tpircher)]

Bernd O. schrieb:
> Karl heinz Buchegger schrieb:
>> Er behandelt a[i]
>> so, als ob du  *(a+i)  geschrieben hättest.
> War's nicht eher *(a+(i*sizeof(a[0])))

Nein, dieser Code ist nicht identisch mit a[i]. Der C Standard legt 
fest, dass a[i] identisch mit *(a + i) ist. Wenn ein Pointer und ein 
Integer addiert (oder subtrahiert) werden, dann wird der Integer 
implizit mit sizeof(*a) multipliziert.

Das hatten wir heute schon einmal in 
Beitrag "*(byMessage + i) identisch byMessage[i]" durch. ;)

[Klaus W. (mfgkw)]

@Bernd O.:

nein.

Zum letzten Mal: a[i] ist gleichbedeutend mit *(a+i) ist
gleichbedeutend mit *(i+a) ist gleichbedeutend mit i[a].

Implizit wird dann i mit der Größe von *a multipliziert,
nicht mehr auf Quelltextebene.

Also ist die Gleichsetzung von a[i] mit *(a+(i*sizeof(a[0])))
einfach FALSCH.

[Karl H. (kbuchegg)]

Bernd O. schrieb:

>> Er behandelt
>>
>>     a[i]
>>
>> so, als ob du  *(a+i)  geschrieben hättest.
> War's nicht eher *(a+(i*sizeof(a[0])))

Du meinst eher

    * (typeof(*a)*)( ((char*)a) + ( i * sizeof(*a) ) )

Dann stimmt es (wenn ich mal so frei sein darf und einen Operator typeof 
postulieren darf), da sizeof(char) per Definition 1 ist. Aber ansonsten 
steckt die implizite Multiplikation mit dem sizeof schon im Datentyp des 
Pointers mit drinnen. -> Pointerarithmetik. Und die hat nichts mit 
dieser Äquivalenz zu tun.