DELETE() - Wird das Objekt wirklich gelöscht?
-
@StudiengangPanik sagte in DELETE() - Wird das Objekt wirklich gelöscht?:
Abgesehen davon musste ich mich bis jetzt in C# nie so umständlich um die Speicherverwaltung kümmern wie in C oder C++
Wahrscheinlich ist "manuelle Speicherverwaltung" und "zeigen, wie komplex C++ sein kann" das Ziel der Übung.
Ansonsten würde man in C++ deine 28 Zeilen lange Funktion
zeichenketteEinlesen()
einfach durch eingetline
ersetzen. Siehe Beispiel hier: https://en.cppreference.com/w/cpp/string/basic_string/getlineOder du würdest den
operator>>
verwenden, weil du dann beliebige Dinge einlesen könntest und nicht nur Zeichenketten.
-
Puuuuuh....
zeichenketteEinlesen()
gewinnt auch mühelos den Worst-Perfomance Award. Du reservierst für jedes Zeichen, das du eingibst, den Speicher neu. Ja, funktioniert, und ja, das passiert wahrscheinlich schneller als jeder Benutzer tippen kann, aber es ist halt schnarchlangsam, weil Speicheranforderungen teuer sind (teuer im Sinne von kostet CPU Zeit).
Also wenn du wirklich bei dermalloc
Version bleiben möchtest/musst solltest du Speicher mit einer akzeptablen Länge anfordern (sagen wir 100 Zeichen) und erst dann reallokieren, wenn dieser Speicher voll ist. Wenn der Speicher voll ist reallokierst du neuen Speicher und gibst als Größe die bisherige Größe * Faktor an:char* zeichenketteEinlesen() { size_t capacity = 100; size_t size = 0; char* retval = malloc( capacity +1 ); // +1 für abschließende 0 for( ;; ) { char ch = getchar(); if( ch == '\n' ) { retval[size] = 0; return retval; } if( size == capacity ) { capacity *= 1.5; retval = reinterpret_cast<char*>( realloc( retval, capacity +1 ) ); // wieder +1 für abschließende 0 } retval[size++] = ch; } }
Es bleibt aber noch zu sagen, dass das ein Garant für üble Fehler bleibt. Funktionen, die dynamische Objekte erzeugen und den Besitz an den Aufrufer übertragen sorgen dafür, dass einem sowas in größeren Projekten um die Ohren fliegt, weil man sich irgendwann nicht mehr über die Besitzverhältnisse im Klaren ist. Für genau solche Dinge wurde
std::string
gemacht.PS:
Ich habe ja noch die leise Hoffnung, dass der Dozent in Wirklichkeit ein C++ Crack ist und auf RAII hinauswill. Er versucht halt nur seine Kompetenz zu verschleiern.
-
Und was noch niemand zur Sprache gebracht hat:
Beim Kopieren eines Autos fliegt dir das Alles wieder um die Ohren:int main() { Auto a1; a1.setModell( zeichenketteEinlesen() ); // soweit ist noch alles ok. a1.modell zeigt auf die Adresse der Zeichenkette, die in zeichenketteEinlesen einge- // lesen ist und gibt sie in seinem Destruktor wieder frei. Das ist ok, weil der Speicher der Zeichenkette mit malloc // angefordert wurde. Auto a2 = a1; // Boom! Beim Kopieren der Objekte werden deren member kopiert, bei Zeigern einfach der Wert. Sowohl a1.modell // als auch a2.modell zeigen jetzt auf die gleiche Adresse. Im Destruktor von a2 wird a2.modell per free() frei- // gegeben, soweit ist alles ok. Im Destruktor von a1 wird a1.modell ebenfalls freigegeben, aber da a1.modell und // a2.modell auf die gleiche Adresse zeigen wird für die gleiche Adresse 2x free() aufgerufen => Undefined behaviour. }
-
@DocShoe sagte in DELETE() - Wird das Objekt wirklich gelöscht?:
Puuuuuh....
zeichenketteEinlesen()
gewinnt auch mühelos den Worst-Perfomance Award. Du reservierst für jedes Zeichen, das du eingibst, den Speicher neu. Ja, funktioniert, und ja, das passiert wahrscheinlich schneller als jeder Benutzer tippen kann, aber es ist halt schnarchlangsam, weil Speicheranforderungen teuer sind (teuer im Sinne von kostet CPU Zeit).
Also wenn du wirklich bei dermalloc
Version bleiben möchtest/musst solltest du Speicher mit einer akzeptablen Länge anfordern (sagen wir 100 Zeichen) und erst dann reallokieren, wenn dieser Speicher voll ist. Wenn der Speicher voll ist reallokierst du neuen Speicher und gibst als Größe die bisherige Größe * Faktor an:ja, das dachte ich mir eig. auch bei der Aufgabenstellung dass das mehr Sinn macht aber Anforderung war dass wir jedes Zeichen den Speicher neu reservieren sollten mit der Begründung man wüsste ja nicht wie viele Zeichen der User eingibt und wenn man dann Speicher für 100 Zeichen reserviert hat und dieser nur 40 eingibt man zu viel Speicher verbraucht. Was teilweise plausibel für mich als Anfänger klingt und das ja auch nur als Übung gilt für malloc/realloc und pointer.
Es bleibt aber noch zu sagen, dass das ein Garant für üble Fehler bleibt. Funktionen, die dynamische Objekte erzeugen und den Besitz an den Aufrufer übertragen sorgen dafür, dass einem sowas in größeren Projekten um die Ohren fliegt, weil man sich irgendwann nicht mehr über die Besitzverhältnisse im Klaren ist. Für genau solche Dinge wurde
std::string
gemacht.dann will ich mal hoffen dass mein Prof langsam mal dazu kommt.
PS:
Ich habe ja noch die leise Hoffnung, dass der Dozent in Wirklichkeit ein C++ Crack ist und auf RAII hinauswill. Er versucht halt nur seine Kompetenz zu verschleiern.ehrlich gesagt keine Ahnung ^^ vertrauen zum Prof oder den Praktikumsleitern bauen die Aufgaben jedenfalls nicht auf.
-
@DocShoe also müsste im Konstruktor neuer Speicher reserviert werden in dem der Wert des Pointers geschrieben wird oder wie in einer obigen Antwort steht dass free() einfach aus dem destruktor löschen?
-
@SeppJ mhh ich denke ich spreche ihn mal darauf an. ^^ Vielleicht habe ich auch einfach einen Fehler gemacht und mal für ein paar Minuten nicht zugehört.
an sich werden uns nur die Aufgaben gegeben und mMn dürftige Dokumentationen über diese Themen die wir dann zur Lösung nutzen sollen. Am Ende verschlägt es mich dann aber doch entweder in Foren wie dieses hier, zu gut und anschaulich erklärende Youtube-tutorials oder eben stundenlanges grübeln ausprobieren bis ich eine funktionierende, anscheinend halbwegs annehmbare, Lösung finde die jedes Wissen aus den Vorlesungen oder der Dokumentation über Bord wirft.
-
@wob oh ja natürlich ^^ in C++ bin ich auch schon über einfachere Methoden zur Einlesung für Zeichen gestoßen wobei ich diese noch nicht ausprobiert habe und zeichenketteEinlesen() entstammt dem ersten Semester (C), indem es wie du schon sagtest um manuelle (dynamische) Speicherverwaltung ging und Arrays.. Schleifen.. pipapow, die wir im zweiten Semester (C++) in dem ich mich jetzt befinde weiterverwenden sollten.
-
Ich finde es lustig wie hier über Code diskutiert wird, von dem wir wichtige Teile noch nichtmal gesehen haben. Wie sieht die Klasse
Auto
aus, was hat sie für Member? Was gibt es noch für Memberfunktionen ausser ctor und dtor und wie sind diese implementiert? Klar, man kann hier einen "educated guess" machen und wird damit vermutlich sogar richtig liegen, aber IMO naheliegend wäre erstmal den OP zu fragen.
-
@hustbaer reicht die Definition der Autoklasse dafür nicht? Wollte hier eig. nicht zu viel Code auf einmal posten, so heißt es jedenfalls im angepinnten "Du brauchst Hilfe" Thema. ^^
aber wenn du sie sehen möchtest. die gesamte .cpp oder nur die .h?
-
@StudiengangPanik
Die cpp reicht, wenn die Funktionen nicht im Header implementiert sind.
-
@CTecS sagte in DELETE() - Wird das Objekt wirklich gelöscht?:
In welchen Metadateien sollte das sein, dafür gibt es die MMU die das Adressmapping macht.
Jede Standardlibrary cached üblicherweise Speicheranforderungen und gibt sie nur nach internen Algorithmen wirklich wieder frei, in dem sie das OS unterrichtet. Das ist deutlich schneller, als alles gleich ans OS durchzureichen. Daher sind Speicherzugriffe auf bereits freigegebene Speicherbereiche möglich, die nicht zu segfaults führen. Ferner kann man bei C oder C++ nicht davon ausgehen, dass überhaupt ein OS darunter liegt, oder dass überhaupt virtuelle Adressräume genutzt werden.
Und nein dem TO hier in jedem 2. Post nahe zu legen das er doch std::string benutzen soll, wird für ihn eine weniger Zielführende Hilfe sein. Er soll sich eben mit der Speicherverwaltung auseinander setzen.
Das ist leider ein Dauerbrenner in diesem Forum.
-
@StudiengangPanik sagte in DELETE() - Wird das Objekt wirklich gelöscht?:
@DocShoe also müsste im Konstruktor neuer Speicher reserviert werden in dem der Wert des Pointers geschrieben wird oder wie in einer obigen Antwort steht dass free() einfach aus dem destruktor löschen?
Kommt drauf an, wie nahe du dich an die Aufgabenstellung halten willst. Wie schon gesagt, merkst du, dass du "richtiges" C++ machst daran, dass du dich nicht mehr um Speicherverwaltung kümmern brauchst. Das ist das, was in der allerersten Antwort mit "Rule of zero" gemeint ist. Wenn du es also wirklich richtig machen willst, dann baust du dein gesamtes Programm total anders auf. Dann lernst du gutes C++, aber bekommst eine schlechte Note von deinem schlechten Lehrer
-
@SeppJ sagte in DELETE() - Wird das Objekt wirklich gelöscht?:
Kommt drauf an, wie nahe du dich an die Aufgabenstellung halten willst. Wie schon gesagt, merkst du, dass du "richtiges" C++ machst daran, dass du dich nicht mehr um Speicherverwaltung kümmern brauchst.
Es kommt wie immer auf den Kontext an. I.d.R. braucht man sich nicht mehr um die Speicherverwaltung zu kümmern, aber es gibt sehr gut begründete Ausnahmen wo man es eben doch tun muss, weil es mit C++ nicht anders geht. Ein Großteil der Problematik resultiert aus Designfehler in der Standardbibliothek.
-
@StudiengangPanik Naja ich persönlich finde es z.B. doof wenn ich raten muss was ein Member wohl für einen Typ haben könnte. In dem von dir gezeigten Code muss
modell
fastconst char*
für sein, aber wie gesagt, sowas raten zu müssen finde ich unspannend.Ebenso die Frage welche Funktionen (speziell welche "speziellen" Funktionen wie z.B. Copy-Ctor und Assignment-Operator) hat die Klasse ausser den gezeigten noch? Vermutlich keine, aber stehen tut das auch nirgends.
Ansonsten... wenn du noch Fragen hast... nachdem du hier ja bereits einiges an Input bekommen hast, wäre vermutlich gut wenn du deinen aktuellen Code nochmal zeigst. Damit man sieht was du jetzt wie umgesetzt hast.
-
#include <iostream> #include <cstdlib> #include <string> #include <iostream> #include <stdio.h> #include "Auto.h" using namespace std; //Standardkonstruktor Auto::Auto() { this->modell = ""; this->anzTueren = 0; this->leistung = 0; } //Initialisierungskonstruktor Auto::Auto(char* modell, int anzTueren, int leistung) { this->modell = modell; this->anzTueren = anzTueren; this->leistung = leistung; } //Getter & Setter void Auto::setModell(char* newModell) { this->modell = newModell; } char* Auto::getModell() { return this->modell; } void Auto::setAnzTueren(int newAnzTueren) { this->anzTueren = newAnzTueren; } int Auto::getAnzTueren() { return this->anzTueren; } void Auto::setLeistung(int newLeistung) { this->leistung = newLeistung; } int Auto::getLeistung() { return this->leistung; } //Ausgabe void Auto::ausgabe() { cout << "\nModell: " << this->modell << "\nTuerenanzahl: " << this->anzTueren << "\nLeistung: " << this->leistung << " PS.\n" << endl; } //Destruktor Auto::~Auto() { if(this->modell != NULL) { //free(this->modell); cout << "\nDas Auto " << this->modell << " wurde geloescht!" << endl; } }
vermutlich ein wenig zu viele bibliotheken aber gut.. und hier wirft nur Zeile 13 eine Warnung
"deprecated conversion from string constant to 'char*' [-Wwrite-strings] "
ich sage es aber nochmal das Programm wurde als bestandene Aufgabe anerkannt. Also ja eventuell ein Armutszeugnis für die Uni.
-
@john-0 sagte in DELETE() - Wird das Objekt wirklich gelöscht?:
@SeppJ sagte in DELETE() - Wird das Objekt wirklich gelöscht?:
Kommt drauf an, wie nahe du dich an die Aufgabenstellung halten willst. Wie schon gesagt, merkst du, dass du "richtiges" C++ machst daran, dass du dich nicht mehr um Speicherverwaltung kümmern brauchst.
Es kommt wie immer auf den Kontext an. I.d.R. braucht man sich nicht mehr um die Speicherverwaltung zu kümmern, aber es gibt sehr gut begründete Ausnahmen wo man es eben doch tun muss, weil es mit C++ nicht anders geht. Ein Großteil der Problematik resultiert aus Designfehler in der Standardbibliothek.
- Wenn schon, dann aber auch richtig und nicht so wie hier
- Diese Ausnahmen kannst du auf der ganzen Welt suchen und hinterher an einer Hand abzählen
-
@StudiengangPanik
Mach dir nix draus, bist nicht der Erste, die Uni/Dozent auch nicht, und es wird auch nicht das letzte mal gewesen sein.
Mach dir klar, dass du Blödsinn für deinen Schein/Klausur lernst, besteh´ das Ganze und dann vergiss es. Wenn du dann irgendwann ein mal C++ lernen möchtest besorgste dir ein gutes Buch (siehe Buchempfehlungen hier im Forum) und fängst von vorne an.
-
#ifndef AUTO_H #define AUTO_H #include <iostream> #include <string> #include <stdio.h> using namespace std; class Auto { private: char* modell; int anzTueren, leistung; public: //Standardkonstruktor Auto(); //Benutzerdefinierter Konstruktor Auto(char* modell, int anzTueren, int leistung); //Getter & Setter void setModell(char* newModell); char* getModell(); void setAnzTueren(int newAnzTueren); int getAnzTueren(); void setLeistung(int newLeistung); int getLeistung(); //Destruktor virtual ~Auto(); //Ausgabe void ausgabe(); }; #endif // AUTO_H
Da die Aufgabe als bestanden anerkannt wurde habe ich jetzt nicht wirklich etwas geändert. Das Thema war ja eig. nur um eine Verständnisfrage zu klären gedacht und bevor ich mir das durch neue Ansätze wieder zerschieße und Fristen nicht einhalten kann habe ich es lieber mal so belassen wie es war. Ich habe mir die ganzen Ansätze aber rausgeschrieben und die in der Studienzeit dann mal durcharbeiten.
-
@DocShoe alles klar ist notiert.
Vielen Dank auf jeden Fall. ^^
-
@SeppJ sagte in DELETE() - Wird das Objekt wirklich gelöscht?:
- Wenn schon, dann aber auch richtig und nicht so wie hier
Ja, er lernt das doch und fragt deshalb hier im Forum nach. Diese ständigen überheblichen Antworten, man mache das in C++ so nicht, sind ein wesentliches Problem hier im Forum. Ein kurzer Hinweis auf eine FAQ o.ä. reicht aus, da muss man nicht den kompletten Thread damit zu müllen.
- Diese Ausnahmen kannst du auf der ganzen Welt suchen und hinterher an einer Hand abzählen
Für HPC ist es eine zwingende Notwendigkeit. Die Standardcontainer sind mit einem Custom Allocator, der NUMA aware ist, nicht mehr benutzbar, da die Standard Container mit so einem Allocator UB haben. Die Speicheranforderung in ganz neuem OpenMP 5.0 (gerade im November 2018 heraus gekommen) erfolgen ausschließlich über C APIs. Dazu muss man für viele Serveranwendungen ebenfalls NUMA aware programmieren. Bei Microcontroller darf man üblicherweise keinen dynamischen Speicher nutzen. usw. usw. usw. …