explicit ifstream ( const char * filename, ios_base openmode mode = ios_base::in);

Wenn ich nun binär Lesen möchte, muss ich dann immer ios_base::binary mit ios_base::in verknüpfen? Weil, wenn ich nur

ifstream in("x.y",ios_base::binary);

mache, geht die ios_base::in Information ja verloren.

Danke im Voraus.

Der Ifstreamkonstuktor kann nicht zaubern und auf magische Weise den Parameter noch mit dem Defaultparameter verknüpfen.

kurz gesagt: Ja.

Danke dir.

doch, ifstream und ofstream zaubern

Bei denen ist explizit immer das Flag ios_base::in bzw: ios_base::out gesetzt (auch wenn man es nicht angibt, d.h. intern wird immer eine Oder-Verknüpfung durchgeführt - der Default-Parameter ist quasi nur ein Hinweis darauf, d.h. technisch sogar überflüssig).

Ich habe dies selber schon öfters so genutzt. Und als Referenz im Internet habe ich http://stdcxx.apache.org/doc/stdlibug/30-3.html (30.3.1.1 The in and out Open Modes) dazu gefunden.

Bei denen ist explizit immer das Flag ios_base::in bzw: ios_base::out gesetzt (auch wenn man es nicht angibt, d.h. intern wird immer eine Oder-Verknüpfung durchgeführt - der Default-Parameter ist quasi nur ein Hinweis darauf, d.h. technisch sogar überflüssig).

Ups, stimmt. Klausel 27.9.1.7.2 im Standard:

explicit basic_ifstream(const char s,
ios_base::openmode mode = ios_base::in);*

Effects: Constructs an object of class basic_ifstream, initializing the base class with basic_-istream(&sb) and initializing sb with basic_filebuf<charT, traits>()) (27.7.2.1.1, 27.9.1.2), then calls rdbuf()->open(s, mode | ios_base::in). If that function returns a null pointer, calls
setstate(failbit).

Hervorhebung durch mich. @gugelmoser, entschuldige die voreilige Antwort, man sollte bei solchen Fragen echt den Standard nochmal explizit lesen, anstatt das zu antworten, an das man meinst sich zu erinnern.
@Th69: Der Defaultparameter ist dazu da, damit man auch einfach gar nix angeben kann. Hätte man natürlich auch durch Überladung lösen können, hat man hier eben mit Defaultparametern gemacht. Spart einen Absatz im Standard .

Th69 schrieb:

Bei denen ist explizit immer das Flag ios_base::in bzw: ios_base::out gesetzt (auch wenn man es nicht angibt, d.h. intern wird immer eine Oder-Verknüpfung durchgeführt - der Default-Parameter ist quasi nur ein Hinweis darauf, d.h. technisch sogar überflüssig).

Ups, stimmt. Klausel 27.9.1.7.2 im Standard:

explicit basic_ifstream(const char s,
ios_base::openmode mode = ios_base::in);*

Effects: Constructs an object of class basic_ifstream, initializing the base class with basic_-istream(&sb) and initializing sb with basic_filebuf<charT, traits>()) (27.7.2.1.1, 27.9.1.2), then calls rdbuf()->open(s, mode | ios_base::in). If that function returns a null pointer, calls
setstate(failbit).

Hervorhebung durch mich. @gugelmoser, entschuldige die voreilige Antwort, man sollte bei solchen Fragen echt den Standard nochmal explizit lesen, anstatt das zu antworten, an das man meinst sich zu erinnern.
@Th69: Der Defaultparameter ist dazu da, damit man auch einfach gar nix angeben kann. Hätte man natürlich auch durch Überladung lösen können, hat man hier eben mit Defaultparametern gemacht. Spart einen Absatz im Standard .

Kein Ding Ich finde es aber trotzdem schöner, wenn man es mit angibt.

Da gibt's doch keinen Unterschied, oder?

Doch. i(f)stream und o(f)stream haben jeweils keine Methoden zum Schreiben bzw. Lesen. Nur wenn ich beides brauche nehme ich auch das, was beides kann. So wird bei Benutzung von fstream auch singalisiert, dass man beides benutzen wird.

ofstream stream("test.txt",ios::out|ios::in);

	if( !stream.is_open() )
	{
		cerr << "Error";
		return -1;
	}

	stream.seekp(9,ios::beg);
	stream << '5';

Logisch, Du nutzt hier ja auch einen ofstream, der nicht für Eingabe gedacht ist.

Eingabe? Ich lese nichts ein, ich gebe etwas aus.

Hm, stimmt, habe das ersetzen mit "suchen + ersetzen" verwechselt. Allerdings navigierst Du eben über bereits erkundetes Terrain, weswegen ich glaube, dass er intern liest, aber eben nichts davon rausrückt. Er muss ja auch wissen, ob der pointer überhaupt an eine gültige Stelle zeigt.

Nein, auch daran liegt es nicht.

ios_base::out by itself causes truncation but that it doesn't cause truncation when it is combined

D.h. ios::out für sich alleine bedeutet immer ios::out|ios::trunc , außer wenn es mit einem anderen Flag verknüpft wird.