Arrays-Logik

Hallo,

Meine Vorstellung von Arrays

Das Array existiert eigentlich nur in unserem Kopf. Eine Array-Dekl.
Ist nichts anderes als das erstellen mehrerer vars auf einem Schlag.
Danach sind diese vars in seperaten Sp.bereichen hintereinander abgelegt. Es
besteht kein Zusammenhang zwischen diesen. Aufgrund der geringen
Groesse des STACKS ist der Arrayname == Sp.adresse des ersten „Feldelementes“ / vars.

Iarray[0] --> Der Trick dahinter ist, dass man mit „iarray“ auf die
Sp.adresse des ersten „Feldelementes“ geht und von dort aus mit dem
Indizierungsoperator auf die einzelnen vars / Sp.adressen zugreift.

Liege ich richtig?

Das was ich nicht verstehe :

mit z. B:
int iarray[5];

Werden nur 5 int vars in sep. Speicherbereichen hintereinander angelegt. Sie sind aber trotzdem unabhängig voneinander. Legen lediglich hintereinander im Speicher. Wieso wird aber trotzdem von einem "Zusammenhang" gesprochen, wenn der Compiler selber nichts von der Dimension weiß && wenn man dazu auch noch das "Array" überschreiten, && ganz normale vars auch als Feldelement behandeln lassen kann?

Swordfish

Wie kommst du darauf, das der Compiler nichts von der Größe des Arrays weiß?

#include <stdio.h>

int main( ) {

	int array[ 5 ];

	printf( "%u\n", sizeof( array ) );
}

name_abcd schrieb:

wenn man dazu auch noch das "Array" überschreiten,

Weil der Compiler Array-Grenzen schlicht nicht überprüft.

name_abcd schrieb:

ganz normale vars auch als Feldelement behandeln lassen kann?

Was meinst du damit?

greetz, Swordfish

PS: Müssen die Operatoren im Fließtext wirklich sein!?

name_abcd schrieb:

Das was ich nicht verstehe :
mit z. B:
int iarray[5];
Werden nur 5 int vars in sep. Speicherbereichen hintereinander angelegt. Sie sind aber trotzdem unabhängig voneinander.

der zusammenhang besteht darin, dass man mit [index], mit 'pointer+x' darauf zugreifen kann und dass sie alle hintereinander im speicher liegen. bei unabhängigen variablen geht das nicht. die können völlig willkürlich im speicher angeordnet sein.

Erstmal danke für deine Antworten,

Ich glaube das der Compiler eher nichts von der Dimension / Grösse weiß , Grund :
bei "sizeof" bedient es sich lediglich an der Deklaration dieses Arrays, ein Beweis dafür --> Wenn du Arrays an Funktionen übergibst , dürfte das mit der Dimension nicht funktionieren.

Was ich mit "Man kann ganz normale vars auch als Feldelement behandeln lassen" gemeint habe : z. B. in der for-Schleife , wenn man das Array überschreitet , kriegt das Compiler überhaupt nicht mit, es behandelt vars außerhalb des Arrays auch als Feldelement.

Der Compiler merkt sich lediglich nur die Sp.adresse des ersten F.elementes --> und mit dem [] - Operator bewegt man sich von dieser Sp.adresse aus.. Wie können wir hier von zusammenhängenden vars sprechen?

naja, ein C-compiler geht davon aus, dass der anwender alles richtig macht und speichert deshalb keine infos wie längenangaben in den arrays selbst. daher ist c-code auch schlank und schnell, aber wenn man nicht aufpasst, kann man sich fiese bugs einhandeln. andere systeme machen compile- und runtime checks bei arrays. man kann jederzeit grösse, typ usw. der arrays abfragen, aber in solchen sprachen ist die benutzung von arrays mit overhead verbunden und zeitaufwändiger als in C.

Danke!

Aber trotzdem : Der Compiler weiß nicht 100% von wo bis wo das Array geht. Definition von Array ist eher : Ein Feld von vars im A.speicher , die alle hintereinander in sep. aufeinanderfolgenden Speicherbereichen liegen. Nach dem Anlegen gibt es das Array im Speicher nicht , sondern nur ganz normale aufeinander folgende vars. Der Compiler weiß lediglich nur die Speicheradresse des ersten "Feldelementes" . Und mit dem [] - Operator können wir von dieser Sp.adresse aus auf alle --> alle ( auch auf die , die nicht zum "Array" gehören ) vars zugreifen. Und der Compiler weiß nur anhand der Array-Deklaration : int iarray[5]; wie gross das Array ist, aber trotzdem bei Zugriffen ( z. B. über die for-Schleife ) nicht , wo das Array endet. Das ist auch logisch --> Wegen der geringen Grösse des STACKS ist Arrayname == Sp.adresse des ersten Feldelementes. Von dieser Sp.adresse aus kann man eben auf u.a. nachfolgende Sp.adresse && damit vars zugreifen. Mehr Informationen speichert der Comp. nicht. Es kann höchstens wissen wieviel Byte gross das Array ist ( anhand der Deklaration ) . Aber nicht wo das Array endet...

Was mich verwirrt ist : Trotz der oben stehenden Tatsachen seit ihr davon überzeugt, dass man trotz dieser Tatsachen von einem "Array" / zusammenhängenden vars reden kann

name_abcd schrieb:

Was mich verwirrt ist : Trotz der oben stehenden Tatsachen seit ihr davon überzeugt, dass man trotz dieser Tatsachen von einem "Array" / zusammenhängenden vars reden kann

klar, weil man ja weiss, dass der compiler genau diesen speicherbereich der grösse (sizeof (array)) für die benutzung als array 'name_des_arrays' reserviert hat. wenn man mit einem zu grossen oder negativen index darauf zugreift, dann befindet man sich sonstwo, aber nicht mehr in den definierten grenzen des arrays.

LordJaxom

name_abcd schrieb:

Was mich verwirrt ist : Trotz der oben stehenden Tatsachen seit ihr davon überzeugt, dass man trotz dieser Tatsachen von einem "Array" / zusammenhängenden vars reden kann

Was mich verwirrt ist: Wieso sprichst Du immer von separaten aufeinanderfolgenden Speicherbereichen? Der Speicher ist wie eine riesengroße Variable, die beliebig eingeteilt werden kann. Was ist da separat?

Und wo ist für Dich der Unterschied zwischen einem Feld aufeinanderfolgender Variablen und mehreren separaten aufeinanderfolgenden Variablen?

name_abcd schrieb:

Der Compiler weiß nicht 100% von wo bis wo das Array geht.

Doch, der Compiler weiß 100% wie groß das Array ist. Diese Information geht erst verloren, wenn Du die Startadresse des Arrays in einen Zeiger umwandelst.

groovemaster

name_abcd schrieb:

Aber trotzdem : Der Compiler weiß nicht 100% von wo bis wo das Array geht. Definition von Array ist eher : Ein Feld von vars im A.speicher , die alle hintereinander in sep. aufeinanderfolgenden Speicherbereichen liegen. Nach dem Anlegen gibt es das Array im Speicher nicht , sondern nur ganz normale aufeinander folgende vars. Der Compiler weiß lediglich nur die Speicheradresse des ersten "Feldelementes" . Und mit dem [] - Operator können wir von dieser Sp.adresse aus auf alle --> alle ( auch auf die , die nicht zum "Array" gehören ) vars zugreifen. Und der Compiler weiß nur anhand der Array-Deklaration : int iarray[5]; wie gross das Array ist, aber trotzdem bei Zugriffen ( z. B. über die for-Schleife ) nicht , wo das Array endet. Das ist auch logisch --> Wegen der geringen Grösse des STACKS ist Arrayname == Sp.adresse des ersten Feldelementes. Von dieser Sp.adresse aus kann man eben auf u.a. nachfolgende Sp.adresse && damit vars zugreifen. Mehr Informationen speichert der Comp. nicht. Es kann höchstens wissen wieviel Byte gross das Array ist ( anhand der Deklaration ) . Aber nicht wo das Array endet...

Du hast hier einige Verständnisprobleme. Erstmal, der Array Name ist keine Adresse. Und dafür wird auch kein extra Speicher benötigt. Dorthin kommen wir erst, wenn wir über dynamischen Speicher reden. Das soll jetzt aber nicht das Thema sein. Betrachte den Array Namen eher als Referenz auf das Array. Und bei Bedarf kann dieser in eine Adresse, welche auf den Anfang des Arrays verweist, umgewandelt werden. Ein Beispiel hierfür ist Zeigerarithmetik. Bis dahin kennt der Compiler die Dimension des Arrays, und kann, sofern das zur Übersetzungszeit möglich ist, Zugriffe auch prüfen. Wo genau das Problem mit dem "aufeinanderfolgen" liegen soll, verstehe ich allerdings nicht. Vielleicht hilft es dir ja, wenn du Nicht-Array Variablen als Array Variablen der Länge 1 betrachtest.

Zu erwähnen ist noch die Parameterübergabe bei Funktionen:

int foo(char bar[5])

Auch wenn das wie ein Array ausschaut, es wird letztendlich nicht wie eines übergeben. In der Funktion kommt einfach nur ein Zeiger an.