klasse/dynamischer Array/Konstruktor



  • Hey Leute,

    habe kürzlich mit der oop angefangen und benötige ansätze zum bearbeiten einer übungsaufgabe die da lautet:

    Entwickeln Sie eine Klasse IntVector, welche ein int-Array (Typ int 😉 von gegebener Länge kapselt.
    1. Die Klasse verfügt über
    • einen Konstruktor, welcher als Parameter die Länge (Typ unsigned) des dynamisch anzulegenden
    int-Array angibt,
    • einen Destruktor,
    • eine Methode size(), mit der sich die Länge der Liste abfragen lässt.
    • eine Methode at(), welche eine Referenz auf das i-te Element des int-Array zurück liefert,
    falls i ein gültiger Index ist. Bei einem ungültigen Index bricht die Methode das Programm
    mit der Fehlermeldung index overflow ab.
    • eine Ausgabefunktion out(), welche den gekapselten int-Array zeilenweise ausgibt.

    #include <iostream>
    using namespace std;
    
    class IntVector
    {
    
    private:
    unsigned LEN;
    int * array;
    
    public:
    
     IntVector(unsigned len);
     ~IntVector();
    
     inline int IntVector::size()const
    
     {
    	 return LEN;
     };
    
     int& at(unsigned i);
     void out();
    };
    
     inline IntVector::IntVector(unsigned len) {
     	LEN = len;
     	array = new int[LEN];
     };
    
    int& IntVector::at(unsigned i)
     {
    
     if(i <= LEN)
    
    	 return array[i];
    
     else
    	 cerr << "index overflow" << endl;
    
     	 delete [] array;
     }
    
    #endif /* HEADER_H_ */
    

    es ist etwas durcheinander, allerdings schaffe ich es nicht systematisch an die sache ranzugehen 🙄 .



  • Und hast du auch eine Frage?



  • ob konstruktor und abfrage zur länge richtig interpretiert wurden 😕



  • agX schrieb:

    ob konstruktor und abfrage zur länge richtig interpretiert wurden 😕

    Wenn ich so eine Antwort lese, reicht es mir.



  • entspann dich, das ist meine erst "richtige" zu lösende Aufgabe.
    Ist klar dass man regelrecht erschlagen wird.


  • Mod

    Folgende Dinge passen nicht zur Aufgabe:

    • Die at-Funktion löscht das Array in jedem Fall. Whitespace ist in C++ kein syntaktisches Element, du musst Codeblöcke mit geschweiften Klammern kapseln.
    • Das Fehlerverhalten der at-Funktion passt nicht zu den Anforderungen, es war ein Programmabbruch gefordert.
    • Die at-Funktion prüft nicht richtig die Länge. Ein Array mit X Elementen hat gültige Indizes von 0 bis X-1 (einschließlich).
    • Die out-Funktion fehlt komplett.
    • Es war kein Destruktor gefordert. Du deklarierst trotzdem einen, implementierst ihn aber nicht. Es ist daher unmöglich, deine Klasse zu instanziieren. Ich gehe daher davon aus, dass du dein eigenes Programm nicht ein einziges Mal getestet hast! Denn dann wäre dieser Fehler sofort aufgefallen. Das ist natürlich keine gute Art und Weise zu programmieren.

    Jetzt das große ABER:
    Die Aufgabenstellung ist absoluter Schrott. Absolut hinterletzter Schrott. Es lehrt dich sämtliche Antipatterns, wie man solch eine Problemstellung niemals in C++ angehen sollte. Wenn ich dir böses wollte, könnte ich kaum eine schlechtere Aufgabe stellen. Der Aufgabensteller hat offensichtlich selber absolut keine Ahnung, wie es richtig ginge. Die Aufgabe ist eine Mustersammlung sämtlicher Designfehler, die Anfänger oft machen. Du wirst von diesem Lehrer nicht glücklich werden. Wie ein Fahrlehrer, der dir beibringt, stets rückwärts zu fahren, weil er denkt, so wäre es richtig. Du wirst entweder niemals richtig Autofahren und frustriert aufgeben, oder du wirst später alles vergessen und nochmals alles von Anfang an neu lernen müssen.



  • - es fehlt der Destruktor
    - ein "delete" hat im "at" nichts zu suchen
    - bitte beachte die Rule of three, d.h. entferne unbedingt den Copy-Constructor oder implementiere ihn sinnvoll.

    Edit: sehe gerade SeppJs Post. Schließe mich dem "Aber-Absatz" an.



  • vielen dank für eure Antworten!

    Ich habe im vergangenen Monat mit der OOP angefangen und steig noch nicht wirklich ein. Bei Fragen zum Stoff blockiert unser Prof mit der Begründung
    man könne es sich ganz einfach alles eigenständig aneignen.

    Zur Aufgabenstellung selbst kann ich leider nicht viel sagen bzw abwegen
    ob es bullshit ist oder nicht da mir dafür einfach die Erfahrung fehlt.

    Ich überarbeite einfach mal die einzelnen Kapitel in der Hoffnung das
    ein gedanklicher Zusammenhang entsteht.

    Danke für eure Antworten 🙂



  • agX schrieb:

    Zur Aufgabenstellung selbst kann ich leider nicht viel sagen bzw abwegen
    ob es bullshit ist oder nicht da mir dafür einfach die Erfahrung fehlt.

    Naja ich finde SeppJ übertreibt. Zum einen ist ja sehrwohl gefordert, einen Destruktor zu schreiben. Zum anderen ist das eine ganz typische Aufgabe zur Vermittlung der manuellen Speicherverwaltung. Wo hier Antipatterns sein sollen, sehe ich nicht. Der STL-Vektor arbeitet sehr ähnlich, nur, dass er noch viel mehr Features (wie Vergrößerung etc.) unterstützt.
    Es geht bei Lernzwecken auch nicht darum, sofort den absolut perfekten Vektor inklusiver aller komplizierteren Themen wie Exceptionsicherheit nachzuimplementieren oder die Rule of 3/5 zu erfüllen. Der TE schreibt hier weder irgendwelchen Library-Code, noch macht er hier Anwendungsentwicklung.
    Du bist auf einen richtigen Weg und du kannst beim Implementieren und Verbessern so einer Array-Klasse sehr viel über C++ lernen. 👍



  • Jodocus schrieb:

    Zum anderen ist das eine ganz typische Aufgabe zur Vermittlung der manuellen Speicherverwaltung. Wo hier Antipatterns sein sollen, sehe ich nicht.

    Es fängt ja schon damit an, dass überhaupt manuelle Speicherverwaltung gelehrt wird. Sowas gehört heutzutage einfach nicht (mehr) in einen Anfängerkurs.



  • SG1 schrieb:

    Jodocus schrieb:

    Zum anderen ist das eine ganz typische Aufgabe zur Vermittlung der manuellen Speicherverwaltung. Wo hier Antipatterns sein sollen, sehe ich nicht.

    Es fängt ja schon damit an, dass überhaupt manuelle Speicherverwaltung gelehrt wird. Sowas gehört heutzutage einfach nicht (mehr) in einen Anfängerkurs.

    Also in Stroustrup's Buch wird das Thema gleich nach der Einführung von std::vector behandelt. Manuelle Speicherverwaltung absolut zu verteufeln ist albern. Man ruiniert schon nicht den C++-Schüler, nur, weil man ihm mal das Wörtchen new zeigt bzw. einmal darlegt, wofür Destruktoren so praktisch sind.



  • Ich glaube auch, dass das Verständnis für manuelle Speicherverwaltung und deren Tücken fundamental wichtig sind. Zumal dann auch klar wird, warum Containerklassen/smart pointer so viel besser sind als manuelle Speicherverwaltung.

    Was hier manchmal übersehen wird ist die Möglichkeit, dass in einem C++ Kurs/Vorlesung der fehleranfällige Weg der manuellen Speicherverwaltung zur Benutzung der STL Klassen erarbeitet wird. Das mag nicht oft der Fall sein, aber eine Übungsaufgabe sofort mit einem Shitstorm zu überziehen finde ich übertrieben. Die Übungsaufgabe ist so gestellt, also muss sie auch so gelöst werden. Dabei kann man TE helfen oder nicht, das bleibt halt jedem selbst überlassen. Natürlich kann man dazuschreiben, dass die manuelle Speicherverwaltung fehleranfällig ist und dass die STL da deutlich komfortablere und sicherere Lösungen anbietet.



  • Manuelle Speicherverwaltung ist ähnlich wie beim Renovieren sich die Wandfarben selbst zusammenmischen wollen, statt dies im Geschäft von der Maschine erledigen lassen.

    Das macht man einmal und nie wieder, finde ich.



  • lemon03 schrieb:

    Das macht man einmal und nie wieder, finde ich.

    Ich hab noch nie ein grösseres Projekt gesehen, wo nicht mindestens eine uralt-schrott-Komponente drin war.

    Wenn man den allgemeinen Trend hier im Forum beherzigt, dann darf man die Komponenten nicht verstehen und soll beten, dass alles gut geht.

    Hinweis darauf, dass manuelle Speicherverwaltung Mist ist: gerne;
    Immer so zu tun, als ob das geheimes, verbotenes Wissen ist: äh, nee.

    (meine dich, lemon03, da jetzt nicht speziell, eher die generelle Tendenz hier im Forum).


Log in to reply