Destruktor für einfache Linked List, Speicherverwaltung
-
Danke für die Antworten.
Ich lerne mithilfe von 2 Büchern (Accelerated C++ und C++ primer plus). Was gibt es denn für aktuelle Alternativen?
Ich weiß, dass man besser Funktionen der Standard Library verwenden sollte, ich wollte die Liste nur so als Übung schreiben.
Was die cout's angeht, wie sonst signalisiert man dem Nutzer, dass was schief gelaufen ist? Boolean als Rückgabewert?
-
@alfons19 Mit Exceptions z. B. so:
void machwas() { throw std::runtime_error{"Error"}; } int main() try { machwas(); } catch (const std::runtime_error& e) { std::cerr << e.what() << '\n'; return 1; } catch (...) { std::cerr << "An unknown error has occured.\n"; return 2; }
Kommt auch immer ein bisschen darauf an, was für Fehler es sind.
Ganz wichtig: Im Destruktor keine Exceptions werfen!
"The list is already empty." und "List deleted.\n" würde ich jetzt auch nicht als Fehler bezeichnen.
@mgaecklerWarnung 126 warning C4365: "Argument": Konvertierung von "int" in "unsigned int", signed/unsigned-Konflikt. C:\CRESD\Source\GAK_CLI\TOOLS\mirror.cpp 1459 1 mirror
Na siehste, hättest da einen int statt unsigned genommen, wär die lästige Warnung nicht da :o)
-
-
@HarteWare sagte in Destruktor für einfache Linked List, Speicherverwaltung:
Warnung 126 warning C4365: "Argument": Konvertierung von "int" in "unsigned int", signed/unsigned-Konflikt. C:\CRESD\Source\GAK_CLI\TOOLS\mirror.cpp 1459 1 mirror
Na siehste, hättest da einen int statt unsigned genommen, wär die lästige Warnung nicht da :o)
Ich nehme jetzt einfach mal an, daß Du nur einen Spaß machen wolltest.
-
@mgaeckler sagte in Destruktor für einfache Linked List, Speicherverwaltung:
Warnung 126 warning C4365: "Argument": Konvertierung von "int" in "unsigned int", signed/unsigned-Konflikt
Kommt bei uns im Code paar Millionen mal vor, third party libs nicht eingerechnet (Google achtet z.B. überhaupt nicht drauf). Da achtet keiner mehr drauf.
-
@Mechanics Das ist natürlich schlecht. Sollte nicht sein.
-
@mgaeckler sagte in Destruktor für einfache Linked List, Speicherverwaltung:
@Swordfish Ja und? Wo siehst Du da einen Widerspruch?
Probiers doch einfach aus inkl. Verifikation. Ich drück' dir alle drei Daumen die ich habe.
-
@Swordfish Ich sehe trotzdem keinen Widerspruch. Ich habe ja nicht behauptet, daß man IMMER unsigned nehmen soll.
-
@mgaeckler sagte in Destruktor für einfache Linked List, Speicherverwaltung:
@Swordfish Ich sehe trotzdem keinen Widerspruch. Ich habe ja nicht behauptet, daß man IMMER unsigned nehmen soll.
ließ es, god damnit!
-
@Swordfish sagte in Destruktor für einfache Linked List, Speicherverwaltung:
ließ es, god damnit!
Was soll ich lesen?
-
einen
unsigned
von einem stream du horst.
-
Das ist ja nicht zum Aushalten! Hier:
https://ideone.com/mtlDpO
Alle mitgedacht? Alle verstanden?
-
@SeppJ sagte in Destruktor für einfache Linked List, Speicherverwaltung:
Das ist ja nicht zum Aushalten!
Du schaffst das! Ich glaub ganz ganz fest an Dich!
-
@Swordfish sagte in Destruktor für einfache Linked List, Speicherverwaltung:
einen
unsigned
von einem stream du horst.Deine Erziehung scheint wohl ein wenig misslungen zu sein.
Nur weil Du ein Beispiel gebracht hast, in dem ein signed Typ einem unsigned Typ vorzuziehen ist, gibt es immer noch keinen Widerspruch zu meiner Aussage.
VG Martin
-
@mgaeckler sagte in Destruktor für einfache Linked List, Speicherverwaltung:
@Swordfish sagte in Destruktor für einfache Linked List, Speicherverwaltung:
Nur weil Du ein Beispiel gebracht hast, in dem ein signed Typ einem unsigned Typ vorzuziehen ist, gibt es immer noch keinen Widerspruch zu meiner Aussage.Naja, schon doch. Du hast schließlich gesagt (und es war deine Hauptaussage, mit der du @HarteWare widersprochen hast!):
@mgaeckler sagte in Destruktor für einfache Linked List, Speicherverwaltung:
@HarteWare sagte in Destruktor für einfache Linked List, Speicherverwaltung:
Das ist kein guter Grund, unsigned zu verwenden. Als Faustregel: Verwende nur unsigned, wenn Du die speziellen Eigenschaften benötigst (overflow, oder für Bit-Operationen), oder wenn Dich die tolle Standardbibliothek mit ihrem size_t dazu nötigt. Grund: Wenn z. B. eine negative Zahl ein fehlerhafter Wert wäre, könntest Du dies bei signed erkennen und darauf reagieren. Bei unsigned wird aber der Fehler sozusagen "vertuscht".
Wer hat Dir den Unfug beigebracht? Wenn ich nur positive Werte gebrauchen kann, nehme ich einen unsigned Typ und ich muß nie überprüfen, ob mir ein Penner einen negativen Wert übergeben hat:
Das ist aber, wie du siehst, nicht wahr. Es ist sogar das absolute Gegenteil der Fall, also das was @HarteWare gesagt hat. Also von wegen Unfug, sondern du hast Unfug erzählt.
-
@SeppJ Werte, die von außen kommen, müssen immer validiert werden. Ich habe nie behauptet, daß das nicht notwendig ist. Ich weiß echt ned, was Ihr habt's. Zuviel Java gemacht?
-
@mgaeckler Sehr interessant! Hab deinen Satz jetzt 10 mal gelesen und kann nicht verstehen, was man an deiner Aussage nicht verstehen kann.
Aber irgendwie muss man den offensichtlich auch falsch verstehen können.
Mal mit eignen Worten:Die Aussage "man soll unsigned nur verwenden für overflow und bit-operationen" findet mgaeckler falsch. Ich auch.
@SeppJ Hast du dich darauf bezogen und findest die Aussage richtig?
-
Das gilt auch in allen anderen Fällen. Was sind denn die Vorteile, wenn man unsigned benutzt? Keine. Denn die Aussage, dass man nicht mehr Validieren muss, muss geändert werden zu dass man nicht mehr validieren kann, egal ob man muss oder nicht. Mit signed kann man also optional validieren, mit unsigned nicht. Man steht also in jeder Hinsicht schlechter da, als wenn man einen signed Typen benutzt hätte.
Dass unsigned durch sein Überlaufverhalten auch technische Optimierungen durch den Compiler erschwert (Schleifen mit unsigned als Zähler laufen beispielsweise potentiell langsamer!) sollte auch nicht ganz unerwähnt bleiben.
unsigned sollte man daher dann und nur dann benutzen, wenn man die speziellen Eigenarten benötigt. Was durchaus öfters vorkommt, aber nicht so häufig, wie viele denken.
-
@Jockelx Ich glaube, @Swordfish geht es hierum (auch wenn man lesen ohne ß schreibt und Horst ein normaler Name ist):
root [0] stringstream ss("-1"); root [1] unsigned u{}; root [2] ss >> u; root [3] u (unsigned int) 4294967295 root [4] (bool) ss (bool) true
Das darf einen schon überraschen. Ich frage mich ernsthaft, wer sich warum dieses Verhalten ausgedacht hat. Nur: das wrappt immer weit in den Riesengroß-Bereich und daher fängt man es mit einem Kleiner-als-Max-Check üblicherweise.
-
@SeppJ sagte in Destruktor für einfache Linked List, Speicherverwaltung:
Das gilt auch in allen anderen Fällen. Was sind denn die Vorteile, wenn man unsigned benutzt? Keine. Denn die Aussage, dass man nicht mehr Validieren muss, muss geändert werden zu dass man nicht mehr validieren kann, egal ob man muss oder nicht.
Mein Beispiel hast Du wohl nicht gelesen?