StartseiteVon Bits und Bytes

Programmieren Teil 7 – Datentypen und Arrays

Von / 30. April 2013 / 22 Kommentare / Seite 3 von 3 / Auf einer Seite lesen
Mehr 
int add( int as[10], int i, int j )
{
    return as[i] + as[j];
}

Was ist nun aber, wenn wir beim Schreiben des Programmcodes noch nicht genau wissen, wie groß ein Arrays sein muss, um alle benötigten Daten aufzunehmen? Intuitiv könnte man annehmen, dass der folgende Code das Problem löst und ein Array der Größe n deklariert:

int n;
...
n = ...
...
int as[n];

Das funktioniert allerdings nicht, und zwar aus einem ganz einfachen Grund: bei einer Variablendeklaration in C++ muss der Compiler zur Kompilierungszeit bereits wissen, wie viel Speicher die Variable benötigt, um entsprechenden Code generieren zu können. In der obigen Konstellation wäre die Größe des Arrays zur Zeit der Kompilierung aber nicht bekannt und dem Compiler wäre nicht bekannt, wie viel Platz auf dem Stack reserviert werden müsste. Wir benötigen also einen anderen Mechanismus, um Speicher erst zur Laufzeit reservieren zu können. Das Schlüsselwort hierfür ist der Heap – was das aber genau ist, werden wir im nächsten Artikel sehen.

1 / 2 / 3
Stichworte: , , ,
Mehr

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.
    https://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:

    https://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.