Danke im Voraus.

Kurz gesagt: Unsinn. Da geht nie etwas verloren.

Ich kann ja jetzt so viele Zahlen eintippen wie ich lustig bin. Alles das ich eintippe landet in einem Puffer, und wird erst geflusht, wenn ich Enter drücke. Ist das korrekt? Falls ja, dann kann der Puffer doch theoretisch irgendwann überlaufen.

Alles das ich eintippe landet in einem Puffer, und wird erst geflusht, wenn ich Enter drücke. Ist das korrekt?

Jain. Der Standard macht darüber keine Aussage, das gehört also weder zu C++ noch zu deinem Programm im engeren Sinne und ist Sache des Betriebssystems. Dieses wird allerdings irgendeine maximale Puffergröße haben, ab der du nichts mehr eintippen kannst. Ob du die rausfinden willst ist eine andere Sache.

Ich lese im Moment meine erstes C++ Buch. Da steht nun folgendes:

Das Schreiben (ofstream) geschieht gepuffert, indem in einen dafür reservierten Speicherbereich (Puffer) geschrieben wird, der erst bei Überlauf oder bei Aufruf von close() auf die Festplatte transferiert wird.

Das habe ich verstanden. Dann steht aber noch dran, dass fürs Lesen (ifstream) analoges gilt. Und das habe ich nicht ganz verstanden. Inwiefern analoges?

{
    ifstream in("test.txt");
} // close

Lädt diese Anweisung nun den Inhalt der File in einen Puffer? Falls ja, wohin soll der Inhalt des Puffers nun transferiert werden?

{
    ifstream in("test.txt");
} // close

Lädt diese Anweisung nun den Inhalt der File in einen Puffer? Falls ja, wohin soll der Inhalt des Puffers nun transferiert werden?

Kann sin, dass da was gepuffert wird, wird in den meisten Fällen auch so sein. Aber meistens auch erst, nachdem du anfängst, irgendwo zu lesen, dann wird im Puffer noch das gerade gelesene bereit gehalten und eventuell auch schon ein bisschen weitergelesen, während dein Programm noch arbeitet. An der Stelle wo die Datei geschlossen wird, wird der Inhalt eines eventuellen Puffers verworfen (da der ifstream nix rausschreiben kann). Aber was hat dieses Beispiel mit deiner Frage zu tun?

Aber was hat dieses Beispiel mit deiner Frage zu tun?

Eine gute Frage. Ich hab keine Ahnung mehr auf was für einem Trichter ich war, als ich den Thread gestartet hab. Im Endeffektf ist eh nur wichtig zu wissen, dass bei ofstream der Inhalt erst dann in die Datei geschrieben wird, wenn sie geschlossen wird.

dass bei ofstream der Inhalt erst dann in die Datei geschrieben wird, wenn sie geschlossen wird.

"erst dann" ist nicht richtig. "auch dann" wäre passend. Es gibt durchaus auch andere Ereignisse, die einen sync auslösen können.

@Gugelmoser: Hast du ein konkretes Problem, weil du MBytes mit cin lesen musst, oder ist das nur so gefragt?

Nein, es war nur eine Frage rein aus Interesse.

aber "new" kann auch NULL zurückgeben

Nein, kann es nicht.

PhilippHToner schrieb:

aber "new" kann auch NULL zurückgeben

Nein, kann es nicht.

Klar kann es das. Man muss das halt anfordern.

Ich weiß. Die Rede ist hier trotzdem von plain new, und du weißt das ganz genau

Dann sag nicht "Nein, kann es nicht.", denn dass ist schlichtweg falsch, sondern schreibe sowas wie "Aber nur, wenn man es explizit fordert". Dann kackt Dir auch keiner ans Bein.

Nur weil du mich nicht magst, musst du nicht gleich darauf rumreiten. Du weißt ja offenbar ganz genau, was ich gemeint habe.

Ehrlich gesagt finde ich Dich gar nciht so schlimm. Nur Deine absoluten Aussagen sind oft einfach Schwachfug. Und Du lässt Dich auch nur extrem schwer eines Besseren belehren. Arbeite da dran, und dann bist Du gar nicht so übel.

PhilippHToner schrieb:

aber "new" kann auch NULL zurückgeben

Nein, kann es nicht.

#define new NULL; //

Jetzt sogar immer!

Nein stimmt schon, es war nicht ganz richtig. Ich müsste den new operator selber bauen und keine exception schmeissen, sondern NULL zurückgeben. Trotzdem finde ich gehört es zur guten Programmiermanier, dass man Pointer überprüft. Ist ja jetzt auch nicht das zentrale Thema.

#define new NULL; //

Jetzt sogar immer!

Ney.

Trotzdem finde ich gehört es zur guten Programmiermanier, dass man Pointer überprüft. Ist ja jetzt auch nicht das zentrale Thema.

Und worauf? Eine Null, die man garantiert nicht bekommt? Wenn du die Funktion der Sprache an sich in Frage stellst, dann kannst du gar nichts mehr Programmieren. Was ist, wenn das if in deiner Prüfung nicht funktioniert? Noch eine Ebene ifs drumherum?

Trotzdem finde ich gehört es zur guten Programmiermanier, dass man Pointer überprüft. Ist ja jetzt auch nicht das zentrale Thema.

Wozu? Wenn Du nicht die nothrow-Variante von new benutzt, dann kommst Du im Ausnahmefall gar nicht erst zu dem Code, in dem Du die Überprüfung durchführst.

PhilippHToner schrieb:

Trotzdem finde ich gehört es zur guten Programmiermanier, dass man Pointer überprüft. Ist ja jetzt auch nicht das zentrale Thema.

Und worauf? Eine Null, die man garantiert nicht bekommt? Wenn du die Funktion der Sprache an sich in Frage stellst, dann kannst du gar nichts mehr Programmieren. Was ist, wenn das if in deiner Prüfung nicht funktioniert? Noch eine Ebene ifs drumherum?

Ich meinte jetzt nicht nur die Variante mit "new" sondern generell das Arbeiten mit Pointern. Woher will der Programmierer wirklich wissen, dass ein Pointer-Parameter gültig ist? Gut er könnte NULL sein und somit auf nichts zeigen, oder er zeigt in den Wald (wo ich nicht überprüfen kann, ob der Wald jetzt gültig ist oder nicht).

Ich arbeite generell so, dass meine Funktionen erstmal die Parameter überprüfen, soweit es geht. Und wenn das new nie NULL zurückgibt habe ich halt schon immer (meist) diese überschüssige Überprüfung gemacht, aber falsch ist sie ja nicht, ich habe nur die bad_alloc exception nie gefangen . Wieso sollte außerdem eine Implementierung mit NULL als Rückgabewert nicht sinnvoll sein? Der C++ Standard definiert es so nicht, aber vielleicht binnen eines Frameworks möchte man nicht die exception Variante.

314159265358979 schrieb:

PhilippHToner schrieb:

#define new NULL; //

Jetzt sogar immer!

Ney.

Du bist doch hier der M_PI Makro Fetischist! Mir ist grad aufgefallen, dass die Variante nur funktioniert, wenn alles in einer Zeile ist :p :p :p