Destruktor für einfache Linked List, Speicherverwaltung
-
@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?
-
Weiteres dazu:
Don't use unsigned for quantities [YouTube, 6:07 min]
CppCoreGuidelines on using unsignedP.S.: Kann natürlich jeder machen, wie er es für richtig hält
Mein ursprünglicher Kommentar sollte lediglich ein gut gemeinter Hinweis sein, und keine ewige Diskussion entfachen.
-
@HarteWare sagte in Destruktor für einfache Linked List, Speicherverwaltung:
Mein ursprünglicher Kommentar sollte lediglich ein gut gemeinter Hinweis sein, und keine ewige Diskussion entfachen.
Ist doch schön, wenn aus einem Kommentar eine Diskussion entsteht.
Zumindest ich hab was gelernt (dachte es wäre recommented z.B. size_t in einem Ctor zunehmen, wenn ich sagen will, dass nur ein unsigned sinnvoll ist).
-
@wob sagte in Destruktor für einfache Linked List, Speicherverwaltung:
@Jockelx Ich glaube, @Swordfish geht es hierum
Blitzgneißer!
@wob sagte in Destruktor für einfache Linked List, Speicherverwaltung:
und daher fängt man es mit einem Kleiner-als-Max-Check üblicherweise.
nein, tut man nicht weils nicht zuverlässig funktionieren kann.
-
@Swordfish Das kannst Du doch sicherlich an Hand eines Beispiels erläutern.
-
@mgaeckler sagte in Destruktor für einfache Linked List, Speicherverwaltung:
@Swordfish Das kannst Du doch sicherlich an Hand eines Beispiels erläutern.
Ist das nicht offensichtlich? Wie unterscheidest du legitime Werte von gewrappten Werten? Gar nicht!
-
@Swordfish sagte in Destruktor für einfache Linked List, Speicherverwaltung:
nein, tut man nicht weils nicht zuverlässig funktionieren kann.
Natürlich kann es zuverlässig funktionieren. Und zwar dann, wenn man einen solchen unsinged-Typ wählt, dessen maximaler gültiger Wert kleiner als die Hälfte des maximal darstellbaren Wertes ist. Dann wrappen alle negativen Zahlen in wesentlich zu große Werte.
Und wenn ich an einen vector-Index mit 64-Bit size_t denke, ist das immer erfüllt. So riesige vectoren habe ich einfach nicht.
-
Dieser Beitrag wurde gelöscht!
-
@wob sagte in Destruktor für einfache Linked List, Speicherverwaltung:
@Swordfish sagte in Destruktor für einfache Linked List, Speicherverwaltung:
nein, tut man nicht weils nicht zuverlässig funktionieren kann.
Natürlich kann es zuverlässig funktionieren. Und zwar dann, wenn man einen solchen unsinged-Typ wählt, dessen maximaler gültiger Wert kleiner als die Hälfte des maximal darstellbaren Wertes ist. Dann wrappen alle negativen Zahlen in wesentlich zu große Werte.
Das sind aber sehr spezifische Voraussetzungen, wenn doch die mit weitem Abstand häufigste Bedingung "nur positive Werte" ist (welche die Voraussetzungen offensichtlich nicht erfüllt).