Struct in Datei schreiben aus CodeGuru.com
-
Kellerautomat schrieb:
int fuer Laengen ist ne Schnapsidee.
In 99% der Fälle ist ein int größer als 16Bit, d.h. mindestens 32Bit und damit völlig ausreichend. In welchem Fall könnte das denn zum Problem werden ?
Aber gut, machen wir ein "uint32_t" draus.
-
Weil ein String groesser als 2(4) GiB gross werden kann.
Weil der Extraktionsoperator ein Minuszeichen vor der Laenge als korrekt sieht und eine negative Laenge setzt.Nimm
std::size_toderstd::string::size_type, die duerften auf 64-Bit Systemen auch 8 Byte gross sein.
-
Arcoth schrieb:
Weil ein String groesser als 2(4) GiB gross werden kann.
Aber kein normaler string sollte so lang werden. Und wenn doch hast du ein Designproblem.
Andere Sprachen limitieren die Länge von strings auch auf 32Bit Integer, und ich habe noch nie gehört dass das ein Problem darstellt.
Arcoth schrieb:
Weil der Extraktionsoperator ein Minuszeichen vor der Laenge als korrekt sieht und eine negative Laenge setzt.
Kommt aber im normalen Gebrauch nie vor. Und wenn ich das Program crashen will, kann ich auch die Länge zu groß/klein machen, oder gleich weglassen...
-
@DarkShadwo44 & Kellerautomat :
Vielen Dank, ist jetzt soweit klar, danke nochmals für euere ausführliche Hilfe.
-
@Darkshadow44: Deine Argumentation ist komisch. Erst einmal die Fakten:
-Mit size_t ist das Programm immer richtig.
-Mit einem anderen Typen manchmal nicht.
Wie kannst du da ernsthaft für die anderen Typen argumentieren? Wenn doch der einzige Unterschied im Code ist, was du an der Stelle des Typs schreibst.uint32_tist ja nicht einmal einfacher zu tippen alssize_t!
-
size_t ist aber plattformabhaengig. Das Richtige ist also, sich auf einen fixen Typen festzulegen und beim Speichern checken, ob die Laenge des Strings in den Typen passt.
-
Kellerautomat schrieb:
size_t ist aber plattformabhaengig. Das Richtige ist also, sich auf einen fixen Typen festzulegen und beim Speichern checken, ob die Laenge des Strings in den Typen passt.
Und inwiefern hilft dabei eine künstliche Beschränkung auf uint32_t? Das Problem bleibt das gleiche, aber dafür funktioniert das Programm suboptimal auf (den vielen) Plattformen, die mehr könnten.
-
Entscheide dich eben, was du willst: Binaer kompatible Files oder Plattformen voll ausnutzen. Beides kriegt du eben nur mit VarInts, aber auch dann kannst du nicht erwarten, dass sich >4GB Strings auf 32-Bit Plattformen lesen lassen.
Deshalb habe ich dem TE auch nicht gesagt "X ist der kanonische Weg" sondern "das sind die Trade-Offs".
-
Kellerautomat schrieb:
Entscheide dich eben, was du willst: Binaer kompatible Files oder Plattformen voll ausnutzen.
Ich wähle: Beides auf einmal! Ich verstehe echt nicht, wo du hier das Problem siehst. Du scheinst irgendwie nur die Hälfte der Beiträge gelesen zu haben und dabei sind dir ein paar wichtige Posts entgangen, die das Missverständnis klären könnten.
-
SeppJ schrieb:
Kellerautomat schrieb:
Entscheide dich eben, was du willst: Binaer kompatible Files oder Plattformen voll ausnutzen.
Ich wähle: Beides auf einmal! Ich verstehe echt nicht, wo du hier das Problem siehst.
Dann erklaer mal, wie das funktioniert. size_t faellt schon mal raus, weil er keine fixe Laenge hat. Was nimmst du?
-
Kellerautomat schrieb:
SeppJ schrieb:
Kellerautomat schrieb:
Entscheide dich eben, was du willst: Binaer kompatible Files oder Plattformen voll ausnutzen.
Ich wähle: Beides auf einmal! Ich verstehe echt nicht, wo du hier das Problem siehst.
Dann erklaer mal, wie das funktioniert. size_t faellt schon mal raus, weil er keine fixe Laenge hat. Was nimmst du?
size_t! Du machst dir Probleme, die gar nicht da sind. Du sollst nicht die Länge binär speichern!
-
SeppJ schrieb:
size_t! Du machst dir Probleme, die gar nicht da sind. Du sollst nicht die Länge binär speichern!
Binaer und formatiert mischen finde ich ganz doof.
-
Kellerautomat schrieb:
SeppJ schrieb:
size_t! Du machst dir Probleme, die gar nicht da sind. Du sollst nicht die Länge binär speichern!
Binaer und formatiert mischen finde ich ganz doof.
Also ein emotionales Argument? Die perfekte(!) Lösung wird nicht genommen, weil der Herr sich nicht wohl fühlt?
-
Kellerautomat schrieb:
Binaer und formatiert mischen finde ich ganz doof.
Ich nicht.
-
SeppJ schrieb:
Kellerautomat schrieb:
SeppJ schrieb:
size_t! Du machst dir Probleme, die gar nicht da sind. Du sollst nicht die Länge binär speichern!
Binaer und formatiert mischen finde ich ganz doof.
Also ein emotionales Argument? Die perfekte(!) Lösung wird nicht genommen, weil der Herr sich nicht wohl fühlt?
Sowas nennt man dann inkonsistent. VarInts koennen genau dasselbe, nur besser.
-
Sowas nennt man dann inkonsistent
Und inwiefern ist das schlecht?
VarInts koennen genau dasselbe, nur besser.
Pauschal: Völliger Blödsinn.
-
SeppJ schrieb:
@Darkshadow44: Deine Argumentation ist komisch. Erst einmal die Fakten:
-Mit size_t ist das Programm immer richtig.
-Mit einem anderen Typen manchmal nicht.Nur in Fällen in denen ein massives Designproblem vorliegt. Niemand braucht einen std::string größer als 4GB!
SeppJ schrieb:
Wie kannst du da ernsthaft für die anderen Typen argumentieren?
Ich sagte ja nicht dass int oder uint32_t besser als size_t wäre.
Klar kannst du auch size_t nehmen, wenn du explizit strings >4GB erlauben willst.
Halte ich allerdings nicht für nötig und würde ich einfach verbieten.
Wenn du es allerdings explizit erlauben willst, dann würde ich zu uint64_t statt size_t tendieren. Dann können auch z.B. 32Bit Programme die Länge der großen Strings einlesen und dann einen Fehler ausgeben statt Mist zu bauen.
-
DarkShadow44 schrieb:
Niemand braucht einen std::string größer als 4GB!
Und was ist mit sicheren Passwörtern?
-
Du definierst den Fall, in dem deine Methode ohne triftigen Grund(!)* versagt, einfach zum Designproblem? Niemand braucht Strings über 4GB? Niemand braucht mehr als 640kB RAM? Niemand braucht Zuhause einen Computer? Niemand wird je Videos aus dem Internet gucken?
*: Dies ist das Verwirrendste von allen. Alle Probleme wären mit einem Schlag gelöst, wenn size_t statt einem anderen Typen genommen würde. Eine einzige Änderung an einer einzigen Stelle, der sonstige Code wäre identisch. Wieso diese Gegenwehr?
-
Mechanics schrieb:
Und was ist mit sicheren Passwörtern?
Die sind keine 4GB ?
SeppJ schrieb:
Du definierst den Fall, in dem deine Methode ohne triftigen Grund(!)* versagt, einfach zum Designproblem?
Fehlerbehandlung fehlt in beiden Varianten, sei es nun die Größe des strings oder ein EOF. Muss man naürlich auch noch einbauen.
SeppJ schrieb:
Niemand braucht mehr als 640kB RAM? Niemand braucht Zuhause einen Computer? Niemand wird je Videos aus dem Internet gucken?
Als ob das vergleichbar wäre.
Bei Arrays sehe ichs ja noch ein, aber definitiv nicht für std::string.
Wie gesagt, wenn du unbedingt 4GB strings willst (was auch immer du mit diesem Monster willst), dann nimm uint64_t:DarkShadow44 schrieb:
Dann können auch z.B. 32Bit Programme die Länge der großen Strings einlesen und dann einen Fehler ausgeben statt Mist zu bauen.
Dann hast du es wenigstens Konsistent, und Nachteile hat das nicht.
