Struct in Datei schreiben aus CodeGuru.com

SeppJ

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!

Kellerautomat

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.

SeppJ

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?

Columbo

Kellerautomat schrieb:

Binaer und formatiert mischen finde ich ganz doof.

Ich nicht.

Kellerautomat

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.

Columbo

Sowas nennt man dann inkonsistent

Und inwiefern ist das schlecht?

VarInts koennen genau dasselbe, nur besser.

Pauschal: Völliger Blödsinn.

DarkShadow44

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.

Mechanics

DarkShadow44 schrieb:

Niemand braucht einen std::string größer als 4GB!

Und was ist mit sicheren Passwörtern?

SeppJ

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?

DarkShadow44

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.

SeppJ

Ich zitiere noch einmal die Frage, vor der du dich die ganze Zeit drückst:

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?

Nenne einen Grund, nicht immer size_t zu nehmen. Einen einzigen! Du hast 0 Nachteile durch size_t, der Code ist identisch! Bei allen anderen Typen hast du eine künstliche Unportabilität und/oder Grenze eingebaut. "inkonsistent", "mag ich nicht", "niemand braucht das", sind alles nur Strohmannargumente. Wo ist der sachliche Grund, nicht size_t zu nutzen?

Bei Arrays sehe ichs ja noch ein, aber definitiv nicht für std::string.

Und womit speicher ich mein OTP? vector<char>, obwohl's doch eine Zeichenkette ist? Wie speicherst du vector<char> ab? Auf einmal doch mit size_t?

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.

Seit wann können 32-Bit Programme nicht erkennen, ob eine Zahl größer oder kleiner ist als eine andere? Wo ist der Unterschied, wenn man da uint32_t oder size_t als Datentyp benutzt? Die Fehlerbehandlung fehlt bei deinem momentanen Code sowieso, aber sie wäre in beiden Fällen immer noch gleich.
Was ist mit 16-Bit Programmen?

Columbo

Als ob das vergleichbar wäre.

Und ob.

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.

uint64_t kann größer sein als size_t . Und da std::string::size_type praktisch immer ein Typedef auf size_t ist wirste da irgendwo einen Überlauf kriegen - aber ohne es zu sehen. std::istream::operator>> würde aber bei size_t - falls die Länge zu groß ist als dass sie reinpasst - in den Fehlerzustand gehen. Das würde das Programm (hoffentlich) registrieren und den Fehler behandeln.

Vorteil size_t : Ist die Länge zu groß für die Lese-Platform merkt das Programm es durch den Fehlerzustand des Streams.
Nachteil uint64_t : Du merkst ohne weiteres nicht dass die Länge zu groß ist. Das Programm wird irgendeinen Schabernack treiben. Sollen wir jedes mal wenn wir deinen uint64_t einlesen explizit prüfen ob er nicht in einen std::string::size_type passt? Sogar wenn der Stream-Operator es für uns tun könnte?

Niemand braucht einen std::string größer als 4GB

Ich brauche einen std::string größer als 4 GiB (bitte Binärpräfixe nutzen), deine These ist widerlegt.

und Nachteile hat das nicht.

Ein Leser deines Codes wird sich fragen warum zum Teufel du uint64_t für die Länge verwendest, denn deine Argumentation wird er nie im Leben nachvollziehen können (zumal sie glücklicherweise nicht bekannt ist).

Kellerautomat

Ich stimme mal DarkShadow44 zu. Ihr habt doch alle einen an der Waffel.

Kellerautomat schrieb:

Ich stimme mal DarkShadow44 zu. Ihr habt doch alle einen Finderabdruck an der essbaren Waffel.

Irgendwann wirst Du dabei noch erwischt, wie Du Flüßigkeit in den Briefkasten schüttest und dann klicken die Hanschellen....

SeppJ

Kellerautomat schrieb:

Ich stimme mal DarkShadow44 zu. Ihr habt doch alle einen an der Waffel.

Wenn weiter so sachlich argumentiert wird, kann ich den Thread auch schließen. Möchtest du nicht noch sagen, dass wir hässlich sind und daher keiner Ahnung haben? Oder uns mit Hitler vergleichen?

Kellerautomat

SeppJ schrieb:

Wenn weiter so sachlich argumentiert wird, kann ich den Thread auch schließen.

Was soll ich dazu sagen? Du kommst doch hier mit so nem formatiert/binaer-Mischmasch der die Nachteile von beidem vereint.
Und dann ist dann noch Hacker, der es skandaloes findet, dass es Leute gibt, die mit Strings <4GB auskommen. Unfassbar, verbrennt sie!

Splitte den Thread am besten oder so.

SeppJ schrieb:

Möchtest du nicht noch sagen, dass wir hässlich sind und daher keiner Ahnung haben? Oder uns mit Hitler vergleichen?

Keine Ahnung was das jetzt sein soll. Aber wo du schon danach fragst: Hacker spreche ich in der Tat einige Kompetenzen ab. Er hat in der Vergangenheit schon oft genug bewiesen, dass er keinen Plan hat und sein Verhalten hier bestaetigt das nur ein weiteres Mal.
Was bei dir los ist, weiss ich nicht :p

hustbaer

Kellerautomat schrieb:

Er hat in der Vergangenheit schon oft genug bewiesen, dass er keinen Plan hat und sein Verhalten hier bestaetigt das nur ein weiteres Mal.

Man könnte meinen du spricht über dich selbst.

Kellerautomat

hustbaer schrieb:

Man könnte meinen du spricht über dich selbst.

Keine Ahnung wovon du sprichst, ich hab eigentlich bisher mit relativ wenigen Leuten Probleme gehabt.

Columbo

Er hat in der Vergangenheit schon oft genug bewiesen, dass er keinen Plan hat und sein Verhalten hier bestaetigt das nur ein weiteres Mal.

lol.

Was bei dir los ist, weiss ich nicht

Sobald jemand den du für kompetenter als dich selbst hältst deine Meinung nicht teilt verstehst du die Welt nicht mehr? Ist nichts neues.

Und dann ist dann noch Hacker, der es skandaloes findet, dass es Leute gibt, die mit Strings <4GB auskommen.

Nein, ich halte es nur für angebracht dass der einzige Fall indem Unterschiede der beiden Methoden vorliegen berücksichtigt wird. Und es einfach zu leugnen ist völlig bescheuert.

SeppJ

Kellerautomat schrieb:

SeppJ schrieb:

Wenn weiter so sachlich argumentiert wird, kann ich den Thread auch schließen.

Was soll ich dazu sagen? Du kommst doch hier mit so nem formatiert/binaer-Mischmasch der die Nachteile von beidem vereint.

WTF?

DarkShadow44 schrieb:

Nimm einfach:

void writeString(std::fstream &file, std::string &str)
{
	file << str.length() << ' '; //write length and seperator
	file << str; //write string
}

std::string readString(std::fstream &file)
{
	int len;
	file >> len; // Read length
	file.ignore(); //skip ' '
	std::string data;
	data.resize(len); //reserve space for string
	file.read(&data[0], len); //read string
	return data;

Länge menschenlesbar, String binär. Dummerweise Länge als int.

Deine direkte Antwort darauf:

Kellerautomat schrieb:

int fuer Laengen ist ne Schnapsidee.

Geschichtsverdrehung?

der die Nachteile von beidem vereint.

Erklär mal. Danach frage ich schon seit 5 Seiten. Bisher kam von dir nur "inkonsistent", "mag ich nicht", "braucht keiner", "Hacker ist doof", "du hast einen an der Waffel", usw. Sachgehalt: 0. Aggressives Verhalten: Hoch.

Um mal einen anderen Thread zu zitieren: Du bist gerade dabei, deinen Account zu verbrennen.