cin Puffer

SeppJ

Das läge weit, weit außerhalb des Einflussbereichs der C/C++-Runtime (da cin intern stdin als Quelle benutzt, benutzt es indirekt die C-Runtime), sondern ist normalerweise Sache des Betriebssystemkernels. Der wird technisch irgendwo eine Grenze haben, bei Linux ist das soweit ich weiß eine Speicherseite (also 65kB). Der Puffer deines Programms sagt nach außen bloß "Du willst mir was geben? Ja, nur her damit." oder "Du willst mir was geben? Nein, warte mal, ich bin voll".

314159265358979

Du liest zu viele Science-Fiction Romane. Mag sein, dass das einige Compiler als Extension anbieten, aber Standard-C++ kennt keine Pufferüberläufe.

Ich glaube, ich habe wirklich etwas grundsätzliches nicht verstanden. Darum fang ich jetzt mal ganz von vorne an:

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?

SeppJ

Gugelmoser schrieb:

{
    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?

SeppJ schrieb:

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.

SeppJ

Gugelmoser schrieb:

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.

Tachyon

Wie- und ob gepuffert wird, hängt von der streambuf -Implementierung ab, die der Stream benutzt. Es kann auch sein, dass gar nicht gepuffert wird.

PhilippHToner

@Gugelmoser: Hast du ein konkretes Problem, weil du MBytes mit cin lesen musst, oder ist das nur so gefragt? Weil bestimmt gibt es einen Überlauf, aber "new" kann auch NULL zurückgeben und Hand auf's Herz, wer überprüft das immer?
Eine interessantere Frage wäre, was ist, wenn ich mit cin >> num; eine Zahl einlese, die in num nicht mehr reinpasst.

PhilippHToner schrieb:

@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.

314159265358979

PhilippHToner schrieb:

aber "new" kann auch NULL zurückgeben

Nein, kann es nicht.

Tachyon

314159265358979 schrieb:

PhilippHToner schrieb:

aber "new" kann auch NULL zurückgeben

Nein, kann es nicht.

Klar kann es das. Man muss das halt anfordern.

314159265358979

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

Tachyon

314159265358979 schrieb:

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.

314159265358979

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

Tachyon

314159265358979 schrieb:

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.

314159265358979

Meine Aussage war nicht absolut sondern Kontext-abhängig.

PhilippHToner

314159265358979 schrieb:

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.

314159265358979

PhilippHToner schrieb:

#define new NULL; //
Jetzt sogar immer!

Ney.

SeppJ

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?

Tachyon

PhilippHToner schrieb:

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.