Nun kennen wir zwar weitere Möglichkeiten zur Darstellung von Werten, aber ganz befriedigend ist das auch noch nicht. Stellen wir uns einmal vor, wir wollen 10 ganze Zahlen auf einmal darstellen. Natürlich könnte man dafür 10 Variablen anlegen, aber das ist mühselig und wird umso umständlicher, je mehr Zahlen man darstellen möchte. Weiterhin ist es bei einzelnen Variablen kaum möglich, Algorithmen umzusetzen, welche diese 10 Werte in erst zur Laufzeit bekannter Reihenfolge auswerten sollen. Wir benötigen also eine weitere Struktur, die uns 1. die Deklaration einer Sammlung von Werten gleichen Typs erlaubt und 2. auch einen Zugriff auf beliebige dieser Werte zur Laufzeit gestattet.

Das Mittel der Wahl zu diesem Zweck sind in C++ die sogenannten Arrays (oder deutsch Felder). Ein Array ist, wie angekündigt, eine Sammlung gleichartiger Werte mit wahlfreiem Zugriff auf diese Werte zur Laufzeit. Bei der Deklaration eines Arrays wird üblicherweise dessen Größe mit angegeben, so dass der Compiler bereits bei der Kompilierung berechnen kann, wie viel Speicherplatz auf dem Stack für dieses Array benötigt wird. Die Deklaration eines Arrays erfolgt über die Angabe des zugrunde liegenden Datentyps und der Größe, also etwa folgendermaßen:

int as[10];

Hier haben wir ein Integer-Array der Größe 10 (in den eckigen Klammern) deklariert, also ein Array, welches 10 ganze Zahlen enthalten kann (dass die Größe hinter dem Variablennamen und nicht hinter dem Datentyp steht, ist eine Eigenheit von C++ und etwas bedauerlich, leider aber nicht zu ändern). Möchten wir auf ein bestimmtes Element innerhalb des Arrays zugreifen, erfolgt ebenfalls durch die Nutzung der eckigen Klammern und der Angabe eines Indexes; um etwa dem 5. Element des Arrays einen Wert zuzuweisen, schreiben wir:

as[4] = 10;

Wer jetzt denkt, die 4 wäre ein Tippfehler, der irrt; Arrays sind in C++ 0-indiziert, das heißt, dass das erste Element im Array mit dem Index 0, das zweite Element mit dem Index 1 und so weiter angesprochen wird. Auf den ersten Blick ist das nicht sonderlich intuitiv, aber man gewöhnt sich dran. Möchte man alle Werte eines Arrays gleich bei der Deklaration des Arrays setzen, bietet sich die folgende Schreibweise an:

int as[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

Der folgende Code ist dagegen leider nicht möglich (die Gründe hierfür kenne ich allerdings nicht – wem sie bekannt sind, der möge es in den Kommentaren schreiben):

int as[10]; as = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

Als Index für ein Array lassen sich natürlich nicht nur konstante Zahlen benutzen; auch Variablen, welche eine natürliche (oder ganze) Zahl repräsentieren, können als Index verwendet werden. Das könnte dann etwa so aussehen (warum die Änderung am Array auch außerhalb des Funktionsaufrufes Auswirkungen hat, werden wir in einem zukünftigen Artikel sehen):

void set( int as[10], int i ) { as[i] = 5; }

Hierbei ist übrigens darauf zu achten, dass man sich innerhalb der Grenzen des Arrays aufhält, also keinen Index verwendet, der außerhalb des gültigen Bereiches liegt (für ein Array der Größe 10 gilt also: 0 ≤ i ≤ 9). Leider kann der Compiler in der Regel nicht sicherstellen, dass diese Grenzen im Code eingehalten werden, so dass diese Aufgabe dem Programmierer obliegt. Noch schlimmer ist, dass auch zur Laufzeit des Programms Verletzungen der Array-Grenzen oft nicht bemerkt werden und darin münden, dass mit unsinnigen Werten gerechnet wird oder noch schlimmer, Werte in Speicherbereiche geschrieben werden, wo sie gar nicht hin sollten – es ist also besonders wichtig, sicherzustellen, dass die Grenzen eingehalten werden.

Gerechnet werden kann mit Array-Elementen ebenfalls; in folgendem Code etwa werden das i-te und j-te Element eines Arrays miteinander addiert und als Ergebnis zurückgegeben:

1 / 2 / 3

Kommentare (22)

  1. #1 MartinB
    April 30, 2013

    Hmm, bei deiner set-Funktion machst du von call-by-reference Gebrauch, oder? (Denn es wird doch nur ein Pointer statt des Arrays übergeben…) War das in der Serie schon dran?

  2. #2 Marcus Frenkel
    April 30, 2013

    @MartinB
    Pssst. Großes Geheimnis. Das kommt später. 😉
    Aber um die Frage zu beantworten: bei ganz strenger Definition von call-by-reference haben wir in set ein normales call-by-value; als Value wird nämlich der Zeiger auf das Array übergeben. Die Zuweisung wird natürlich trotzdem nach außen weitergegeben, weil eben auf dem Pointer operiert wird.

  3. #3 MartinB
    April 30, 2013

    @Marcus
    Schon klar, ich dachte nur, dass das Leute verwirren könnte, die das noch nicht wissen.

  4. #4 Marcus Frenkel
    April 30, 2013

    @MartinB
    Vermutlich; ich habe den Text etwas angepasst, danke für den Hinweis.

  5. #5 Nicolai
    April 30, 2013

    Vielen Dank für deine Mühe und die guten Erklärungen – findet man selten!
    Für meinen Geschmack ist bisher nur ein bisschen zu viel C dabei, aber das ändert sich bestimmt noch. 🙂

    Wäre std::array nicht eleganter? Das kann man ja per Value oder per Reference übergeben, je nach Anwendung könnte das praktischer sein..

    Oder wissen wir Leser hier offiziell noch nichts von der Standardbibliothek? 😀

  6. #6 Dr. Webbaer
    April 30, 2013

    Ist die dynamische Typisierung böse?

  7. #7 Marcus Frenkel
    April 30, 2013

    @Nicolai

    Für meinen Geschmack ist bisher nur ein bisschen zu viel C dabei, aber das ändert sich bestimmt noch.

    Das ändert sich noch, ja. Objektorientierung kommt, sobald die Grundlagen da sind. 😉

    Wäre std::array nicht eleganter? Das kann man ja per Value oder per Reference übergeben, je nach Anwendung könnte das praktischer sein..

    Das ist schon zu tief in der OO drin, da fehlen noch einige Grundlagen dafür.

    Oder wissen wir Leser hier offiziell noch nichts von der Standardbibliothek?

    Richtig. 😉

  8. #8 rolak
    April 30, 2013

    5. Element des Arrays..
    as[4] = 10;
    Wer jetzt denkt, die 4 wäre ein Tippfehler

    Nee, in dem Fall nicht, jedoch bei den beiden folgenden Beispielen

    int as[4] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

    int as[4]; as = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

    sehe ich das schon als Tippfehler an. Bzw zu stabiles sample/hold bei c/p 😉

    die Gründe hierfür kenne ich allerdings nicht – wem sie bekannt sind

    As simple as can be: Sprachdefinition.

    Die cliffhanger dieser Serie sind nett…

  9. #9 Marcus Frenkel
    April 30, 2013

    Nee, in dem Fall nicht, jedoch bei den beiden folgenden Beispielen

    Whoops…Copy&Paste ist nicht nur beim Programmieren schädlich…

    As simple as can be: Sprachdefinition.

    Ich hoffe bei so etwas immer auf tiefergehende Gründe und nicht einfach “weil es so gemacht wurde”. Wobei Java einen ja eines besseren belehren sollte…

    Die cliffhanger dieser Serie sind nett…

    Was soll man machen. Wenn alles in einem Artikel steht, schreibe ich zu lang daran und es liest auch keiner mehr. 😉

  10. #10 rolak
    April 30, 2013

    tiefergehende Gründe

    Damals™ bei 8080 und so konnte ich mir ja noch durchaus vorstellen, daß irgendwelche Platz-, Komplexitäts- oder Integrationsprobleme eine Orthogonalität des Befehlssatzes verhinderten. Doch bei heutigen Kernen, insbesondere allerdings (und das schon immer) bei Computersprachen sind mir solch krasse Brüche unverständlich.

    Was soll man machen.

    Aber nicht doch, das war durchaus und ernsthaft positiv gemeint: Nicht nur daß unnötige Fragen gebremst werden, locker eingestreut und insbesondere wie hier als Schlußsatz-Brücke hält sowas durch den offenen Spannungsbogen auch die Aufmerksamkeit wach.

    Millionen Heft{roman}-, Radio- und Fernsehserien können nicht irren…

  11. #11 Stefan W.
    http://demystifikation.wordpress.com/2013/04/09/balkentrager/
    April 30, 2013

    Ist die dynamische Typisierung böse?

    Was für eine unschuldige Frage!

  12. #12 Dr. Webbaer
    Mai 3, 2013

    Auf die ganz blöden Diskussionen – Scope von Variablen, globale Variablen böse, untypisierte Datenstrukturen sowieso, lässt sich ja hier keiner ein, lol. – Ein sicheres Merkmal, dass hier bevorzugt Sacharbeit stattfindet.

    MFG
    Wb

  13. #13 Geralt
    Mai 10, 2013

    ###
    #Der folgende Code ist dagegen leider nicht möglich (die #Gründe hierfür kenne ich allerdings nicht – wem sie #bekannt sind, der möge es in den Kommentaren schreiben):
    # int as[10];
    # as = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
    ####

    “as” dürfte in dem Zusammenhang nur ein Pointer auf einen long-integer Wert (die Anfangsadresse des Arrays) sein. Evtl. klappt’s mit dem Dereferenzierungsopearator, aber sicher bin ich mir hier auch nicht. Direkt zuweisen geht aber bei Pointern natürlich nicht.

  14. #14 Geralt
    Mai 10, 2013

    sry wegen der Formatierung. Wie ging blogqote noch mal?

    bei erfolgreichem Ausführen der zweiten Zeile würde die Startdresse des Arrays auf einen recht komischen Wert überschrieben werden… zum Glück schnallt das der Compiler;)

  15. #15 Marcus Frenkel
    Mai 10, 2013

    <blockquote>Das Zitat</blockquote>

    😉

  16. #16 Geralt
    Mai 10, 2013

    danke.
    merke gerade ich hab alles ein bisschen undeutlich formuliert. Also:
    “as” ist in dem Zusammenhang ein long-int Pointer, der als Wert die Startadresse des Arrays beinhaltet. Die Zeile

    as = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

    bedeutet also, dass der Startadresse des Arrays as ein neuer Wert zugewiesen werden soll, und zwar {1,2,3…}. Das dürfte schon nicht klappen, weil Long-Int nicht mehrere Werte annehmen kann.

    Nutz man zusätzlich den Deferenzierungsoperator, würde man statt der Speicheradresse den Inhalt der Speicheradresse ansprechen. Aber darin dürfte bereits der erste Wert des Arrays befinden, also as[0]. Der erste Wert (wie alle Werte des Arrays as) hat den Typ int. Also versucht man, einen int-Wert auf {1,2,3…} zu setzten, was ebenfalls in die Hose geht sollte.

    Was meint ihr?

  17. #17 Marcus Frenkel
    Mai 10, 2013

    Das erklärt aber nicht ganz, warum die gleiche Syntax bei der gleichzeitigen Deklaration und Zuweisung erlaubt ist.

  18. #18 Geralt
    Mai 10, 2013

    Na ja, dazu müsste man wohl teilweise auch in die Köpfe der Compiler-Entwickler sehen können.

    Aber dass man eine Funktion eingebaut hat um ein Array ohne for-Schleife, oder 10 einzelnen Befehlen (in unserem Fall), zu initialisieren, können wir nachvollziehen. Und dass das in bereits vorhandener Syntax passieren sollte auch.

    Dann stellt sich die Frage wo und wie man die Funktion implementiert. Und warum nicht gleich bei der Deklaration?
    Den (meisten) Compilern ist’s eh “egal”, ob bei der Deklaration von Arrays gleich Werte mit angegeben werden oder nicht, falls ja, werden diese verwendet, falls nicht, wir alles auf 0 gesetzt. In beiden Fällen wird der Inhalt des Arrays bei Deklaration gesetzt.

    Lange Rede kurzer Sinn: ich denke dass die erste Version funktioniert, ist von den Compiler-Entwicklern einfach so gewollt, denn die Funktion an sich macht ja Sinn.

    Daher sehe ich die Frage primär darin, warum es mit der Zwei-Zeilen-Version nicht funktioniert. Technisch ist’s nachvollziehbar (s #16), aber könnte der Compiler nicht trotzdem so agieren wie bei der Deklaration? Dann dürfte die Variable “as” aber nicht nur ein Pointer auf die Startadresse des Arrays sein. Womöglich ist das einfach wieder historischer Speichergeiz…

  19. #19 Marcus Frenkel
    Mai 10, 2013

    Die Compiler-Entwickler haben damit erst einmal direkt nichts zu tun; es steht in der Sprachspezifikation, was erlaubt ist und was nicht. Heißt, hier wurde sich schon bei der Spezifikation überlegt, dass das nicht gestattet sein soll; vielleicht mit Hinblick auf die spätere Implementierung des Compilers, das kann gut sein. Vielleicht hat es aber auch andere Gründe. Ich hatte gehofft, dass die konkreten Gründe jemandem bekannt sind. 😉

  20. #20 michael
    Mai 10, 2013

    > Vielleicht hat es aber auch andere Gründe.

    Etwas dazu findet man hier und in den Verweisen:

    http://stackoverflow.com/questions/3437110/why-does-c-support-memberwise-assignment-of-arrays-within-structs-but-not-gen?rq=1

  21. #21 Dr. Webbaer
    Juli 17, 2013

    Sup!

    Kommt noch was Ergänzendes?

    MFG
    Dr. W

    • #22 Marcus Frenkel
      Juli 17, 2013

      Der nächste Artikel ist in Arbeit und kommt hoffentlich bald.