Ausgabe mit Datein
-
Lymogry schrieb:
Ich beobachte, dass ein "\n" nicht reicht, um in einer DATEI in die nächste Zeile zu kommen, dafür klappts aber mit "\r\n" ...
Den Unterschied zwischen \r und \n hab ich nicht verstanden ...
Unter Windows besteht ein Zeilenumbruch in Dateien (nicht in stringstream) aus \r und \n. Wenn du eine Datei binär einließt, bekommst du beide Zeichen. Ließt du eine Datei im Textmodus ein, bekommst du nur das \n. Dass du aber für eine Ausgabe \r brauchst, ist mir neu
.
-
Lymogry schrieb:
Ich beobachte, dass ein "\n" nicht reicht, um in einer DATEI in die nächste Zeile zu kommen, dafür klappts aber mit "\r\n" ...
Den Unterschied zwischen \r und \n hab ich nicht verstanden ...Öffne die Datei nicht binary!
Auch nicht, warum es schlecht sein soll, den AUSGABEpuffer zu leeren.
Weil du damit auslöst, dass die Daten physisch auf das Ausgabegerät geschrieben werden. Das ist langsam. Richtig langsam. Schnell ist es, wenn möglichst viel auf einmal geschrieben wird und dann auch noch am besten dann, wenn das dafür zuständige System meint, dass ein guter Zeitpunkt wäre. Denn die Menge macht nicht so viel aus, es ist der Zugriff an sich. Das machst du kaputt, wenn du nach jeder Zeile flusht. Denn dann sind das viel zu wenige Daten, als das ein Zugriff sich lohnen würde.
-
Lymogry schrieb:
Nathan schrieb:
Allerdings zwei Dinge:
- endl ist nicht einfach nur eine Ausgabe von '\n', es wird auch geflusht. Meistens willst du das nicht, deswegen schreib einfach nur '\n'Ich beobachte, dass ein "\n" nicht reicht, um in einer DATEI in die nächste Zeile zu kommen, dafür klappts aber mit "\r\n" ...
Den Unterschied zwischen \r und \n hab ich nicht verstanden ...Das ist OS-abhängig. Manche OS brauchen '\n', andere '\r''\n'.
Wenn du die Datei nicht im Binarymodus öffnest, kümmert sich ofstream um die Konvertierung, da musst du dir keine Gedanken machen. Ist das binary-Flag aber gesetzt, wird da nichts konvertiert, sondern Zeichen für Zeichen in die Datei geschrieben (Deswegen sollte man für Textausgabe ja nicht das binary Flag setzten, bei rohen Daten ist das wurscht). Das ist übrigens auch die einzige Besonderheit des binary Flags.Auch nicht, warum es schlecht sein soll, den AUSGABEpuffer zu leeren.
Ich meine, wenn es der Eingabepuffer wäre, kann ich das nachvollziehen, dass man den haben will und auch dass es gut ist, den mal zu leeren, man könnte ja womöglich noch seltsame Zeichen dadrin haben. Aber wozu braucht man den Ausgabepuffer noch, wenn man was ausgegeben hat ....?
Bitte um Erleuchtung!IO von Dateien ist langsam. Da muss erst in Kernel Mode geswitcht werden, indem ein sycall ausgeführt wird, etc. (siehe hier).
Würde das bei jedem Zeichen gemacht, was ausgegeben wird, wäre die Perfomance katastrophal. Deshalb werden die Zeichen erst einmal in einen Puffer geschrieben und der Puffer in die Datei, wenn er voll ist - oder wenn man flusht. flusht man bei jedem Newline auch wenn das überflüssig ist, zieht das die Perfomance runter.Edit: Oh, hab lang gebraucht den Beitrag zu schreiben.
-
Vielen Dank den tollen Antworten!
Wenn ich das jetzt richtig verstehe, könnte endl sogar erzwingen, dass kurz vor einem Crash noch in eine Ausgabedatei geschrieben wird, während das mit \n womöglich noch nicht gemacht wurde? Vorausgesetzt man weiß, wo es buggt ..
-
Lymogry schrieb:
Wenn ich das jetzt richtig verstehe, könnte endl sogar erzwingen, dass kurz vor einem Crash noch in eine Ausgabedatei geschrieben wird, während das mit \n womöglich noch nicht gemacht wurde? Vorausgesetzt man weiß, wo es buggt ..
der destruktor von ofstream flushed natürlich auch (wer schreibt schon "<< std::flush" hin bevor er die datei schliesst?) und der wird ja auch noch aufgerufen wenn etwas wirft.
-
Lymogry schrieb:
Vielen Dank den tollen Antworten!
Wenn ich das jetzt richtig verstehe, könnte endl sogar erzwingen, dass kurz vor einem Crash noch in eine Ausgabedatei geschrieben wird, während das mit \n womöglich noch nicht gemacht wurde? Vorausgesetzt man weiß, wo es buggt ..
Ja, bspw. bei einem Segfault ist es gut, wenn die Daten vorher geflusht werden.
Aus diesem Grund ist cerr ja auch ungebuffert, eben das die letzten Fehlermeldungen noch sichtbar werden, bevor die Anwendung evtl. crasht.
-
Nathan schrieb:
Lymogry schrieb:
Vielen Dank den tollen Antworten!
Wenn ich das jetzt richtig verstehe, könnte endl sogar erzwingen, dass kurz vor einem Crash noch in eine Ausgabedatei geschrieben wird, während das mit \n womöglich noch nicht gemacht wurde? Vorausgesetzt man weiß, wo es buggt ..
Ja, bspw. bei einem Segfault ist es gut, wenn die Daten vorher geflusht werden.
Aus diesem Grund ist cerr ja auch ungebuffert, eben das die letzten Fehlermeldungen noch sichtbar werden, bevor die Anwendung evtl. crasht.Ja genau, an den SegFault hab ich grad gedacht.
Prima, dann gibt es ja sogar einen Anwendungsbereich für endl.
-
was muss man machen um einen "SegFault" zu bekommen?
-
asfdlol schrieb:
was muss man machen um einen "SegFault" zu bekommen?
Irgendein x-beliebiges C/C++-Programm schreiben.
Oder in Speicher der dir nicht gehört.
-
Nathan schrieb:
asfdlol schrieb:
was muss man machen um einen "SegFault" zu bekommen?
Irgendein x-beliebiges C/C++-Programm schreiben.
Oder in Speicher der dir nicht gehört.kann man doch alles mit exceptions lösen. die stl container bieten ja auch at-methoden an z.b.
-
asfdlol schrieb:
Nathan schrieb:
asfdlol schrieb:
was muss man machen um einen "SegFault" zu bekommen?
Irgendein x-beliebiges C/C++-Programm schreiben.
Oder in Speicher der dir nicht gehört.kann man doch alles mit exceptions lösen. die stl container bieten ja auch at-methoden an z.b.
Ja, die stl-container.
Und man kann auch checking für STL-Iteratoren aktivieren.
Und man sollte Pointer vermeiden.
Eigentlich sollte man dann keinen mehr kriegen.
