|
Anzeige
|
Indizes statt Pointer
Gast
#1514641
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? 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!
Gast
#1514681
>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
Gast
#1514687
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. In der Assemblerausgabe. Mir fällt gerade der Compilerschalter nicht ein. Es kann durchaus passieren, dass der Compiler zur Schleifenoptimierung zusätzlich oder alternativ zum laufenden Index einen Pointer mitzieht. 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. 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 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. ;) @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. 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. Antwort schreiben |
Anzeige
|
