Programm stürzt nach korrekter Ausgabe ab.
-
du könntest ja theoretisch auch vor dem anfordern des speichers überprüfen, ob überhaupt schonmal speicher angefordert wurde (nullptr) und diesen speicher dann evtl. freigeben.
-
@Schlangenmensch sagte in Programm stürzt nach korrekter Ausgabe ab.:
Wobei Copy and Swap den Move Kram direkt mit liefert
???
Bitte genauer erklären. Die Idee ist doch, dass ich mir sowas wie "new" sparen kann, da ich den Pointer aus other klaue. Ich will also gerade nicht erst einen Standard-Studenten mit Standard-Name erstellen.
-
Hier nochmal genauer, was passieren sollte... (und auch schon passiert) (habe mein feinstes Englisch ausgepackt...)
void printKlausAndGundula() { const int n = 5000; Student stud = Student("Kleber, Claus", 1234, 1); Student stud2 = Student("Gausel, Gundula", 5678, 1); Student stud3 = stud2; stud2.setSemester(3); cout << stud << endl; // should print 1, because of deep copy cout << stud2 << endl; // should print 3, because of deep copy cout << stud3 << endl; // should print 1, because of deep copy Student studarr[n]; for (size_t i = 0; i < n; i++) { int r = rand() / (RAND_MAX / 3); switch (r) { case 0: studarr[i] = stud; break; case 1: studarr[i] = stud2; break; case 2: studarr[i] = stud3; break; default: break; } } stud.setSemester(0); stud2.setSemester(0); stud3.setSemester(0); cout << studarr[0] << endl; // should print either 1 or 3, because of deep copy through assignment cout << studarr[1] << endl; // should print either 1 or 3, because of deep copy through assignment cout << studarr[n - 2] << endl; // should print either 1 or 3, because of deep copy through assignment cout << studarr[n - 1] << endl; // should print either 1 or 3, because of deep copy through assignment }
-
@wob In dem Beispiel ist der Standard Konstruktor halt blöd, weil der aus einem mir unbekannten Grund bereits Speicher für einen Nichtssagenden String anlegt. Wenn man sich das spart kann man beim Move Konstruktor einfach ein leeres Objekt erstellen und other da rein 'swappen'.
Für move assignment muss man nichts machen, da der bereits definierte mit "call by value" dann, wenn er mit einem r-value aufgerufen wird, den move Konstruktor aufruft.
-
Den Standard Konstruktor habe ich aufgrund dieser Zeile gebraucht:
@EinNutzer0 sagte in Programm stürzt nach korrekter Ausgabe ab.:
Student studarr[n];
also für das n-malige Initialisieren der (auto) Array Elemente. Wenn ihr mir sagt, wie es anders ginge... dann immer her damit.
-
Student *studentmemptr;
also wenn schon dynamische speicherverwaltung, dann richtig.
-
@EinNutzer0 du musst aber im Standard Konstruktor nicht unbedingt mit new schon neuen Speicher anfordern. Wenn du den Standard Konstruktor von std::string oder vector aufrufst, schreibt der ja auch nicht per default irgendwas da rein.
-
@Wade1234 sagte in Programm stürzt nach korrekter Ausgabe ab.:
du könntest ja theoretisch auch vor dem anfordern des speichers überprüfen, ob überhaupt schonmal speicher angefordert wurde (nullptr) und diesen speicher dann evtl. freigeben.
Nix prüfen.
delete nullptr
ist wohldefiniert. Aber Du hast dann den selben Käse wenn das nächstenew
wirft.
-
die ausnahme kann man ja abfangen, oder?
-
@Wade1234 Schon, aber die alten Daten sind weg. Ich zumindest bin (hoffentlich nicht alleine) der Meinung daß assignment operators das Objekt in seinem ursprünglichen Zustand belassen sollen wenn sie ihre Aufgabe nicht erfüllen können.
-
@Swordfish man könnte ja erst versuchen, den neuen speicher anzufordern und dann den alten löschen, oder?
-
@Wade1234 Ja. Und genau das macht man mit Copy-'n-Swap.
-
@Wade1234 sagte in Programm stürzt nach korrekter Ausgabe ab.:
@Swordfish man könnte ja erst versuchen, den neuen speicher anzufordern und dann den alten löschen, oder?
Dann läuft man theoretisch vor das Problem, dass für die neue Anforderung genug Speicher da ist, aber nicht für die neue UND die alte, deren Speicher dann erst später freigegeben werden kann.
-
Dieser Beitrag wurde gelöscht!
-
@Belli sagte in Programm stürzt nach korrekter Ausgabe ab.:
@Wade1234 sagte in Programm stürzt nach korrekter Ausgabe ab.:
@Swordfish man könnte ja erst versuchen, den neuen speicher anzufordern und dann den alten löschen, oder?
Dann läuft man theoretisch vor das Problem, dass für die neue Anforderung genug Speicher da ist, aber nicht für die neue UND die alte, deren Speicher dann erst später freigegeben werden kann.
Das ist halt einer der Preise für strong exception safety.
-
@Belli sagte in Programm stürzt nach korrekter Ausgabe ab.:
Dann läuft man theoretisch vor das Problem, dass für die neue Anforderung genug Speicher da ist, aber nicht für die neue UND die alte, deren Speicher dann erst später freigegeben werden kann.
Korrekt. Und?