cin Puffer

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.

PhilippHToner

SeppJ schrieb:

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