Ich habe eine Methode, die quasi aus großen switch-Statement besteht. Sobald ich in einem der case-Blöcke einen ostringsteam instanziere, stürzt die ganze Methode ab, egal ob ich jetzt wirklich in diesem case-Block war oder nicht. Klartext:

void Klasse::Methode() {
	switch (type) {
		case 1: {
            // [...]
        break; }
	    case 3: {
			ostringstream buffer;
			// Zeugs mit dem buffer
	    break; }
	    case 4: {
            // [usw...]
	    break; }
	}
}

Ob ich jetzt mit type = 3 oder mit irgendwas anderem da reingehe, ist egal. Absturz in jedem Fall.

EDIT: Was mich natürlich auch brennend interessiert: Warum stürzt das überhaupt ab? Da kann man doch eigentlich gar nichts falsch machen!

Hätte mich auch sehr gewundert, wenn allein der Aufruf dieses Konstruktors irgendwie durch äußere Umstände so verändert worden wäre, dass er zum Crash führt.

EDIT: Scheiße. Also kann ja sein, dass ich um die Uhrzeit schon Ausfallerscheinungen habe, aber ich meine trotzdem, dass das gerade eben einmal funktioniert hätte. Und jetzt ist es wieder so wie vorher! Was soll das?

UPDATE: Kann es sein, dass das ganze irgendwie mit der MFC kollidert? Ich habe mal völlig wahllos auch an andere Stellen des Programms solche ostringstreams eingebaut. Grundsätzlich kann ich sagen, dass der Aufruf in Programmteilen, die irgendwie MFC-Klassen verwalten, nicht funktioniert, aber durchaus in jenen, die nur ergänzende Dateiverwaltungsklassen enthalten. Besonders interessant fand ich dabei folgendes:

void CEntityList::OnDestroy() {
        // hier stürzt ein Aufruf ab
	CListCtrl::OnDestroy();
        // hier nicht
}

Im ersten Fall existiert das von der Klasse verwaltete Fenster ja noch, im zweiten Fall wurde es bereits zerstört.

Ich erkenne da jetzt nicht irgendwelche Hintergründe, die zu einer Lösung führen würden, aber zumindest ist es ein gewisses Muster. Kann da vielleicht jemand was zu sagen?

Wahrscheinlich zerschiest du irgendwas im Speicher. Nimm mal nen Debugger und versuch ein bisschen logisch vorzugehen und bau nicht nur irgendwo wirr deinen Code um.

Im übrigen sagte ich nicht, dass die Lib grundsätzlich nicht geht, sondern dass sie nur bei mir möglicherweise irgendwie kaputt sein könnte.

Habe es jetzt auch irgendwie zum Laufen bekommen, indem ich ein völlig unverwandtes Problem woanders gelöst habe... Aber wie es halt so ist: Neues Problem:

Ich habe einen String von der Art "*float*, *float*, *float*", den ich in ein Array aus drei floats eintragen möchte. Dazu mache ich folgendes:

int end;
for (int i = 0; i < 3; i++) {
	end = value.find(',');
	buffer.str(value.substr(0, end));
	buffer >> theFloats[i];
	value.erase(0, end + 2);
}

Hierbei wird aber nur die erste Zahl richtig ausgelesen. Bei den anderen beiden scheint operator >> von buffer einfach nichts zu tun. Bei den ostringstreams habe ich irgendwo, irgendwann mal gelesen, dass der Aufruf von str() dazu führt, dass der Inhalt eingefroren wird, also nichts mehr weiter rein geht. Gilt das denn auch für istringstream? Und wenn ja, wie schafft man es dann, den Inhalt auszutauschen, damit man so ein Objekt überhaupt mehrmals benutzen kann? Das sollte doch möglich sein, oder nicht?

...Im übrigen sagte ich nicht, dass die Lib grundsätzlich nicht geht, sondern dass sie nur bei mir möglicherweise irgendwie kaputt sein könnte...

Dann wäre es wahrscheinlicher das sie in keister Weise läuft. Schreib ein Miniprogram mit stringstream, wenn das läuft, liegt es mit nahezu 100%iger Sicherheit an deinem Programm. Der Absturz an der Stelle heißt auch nicht das der Fehler unbedingt dort liegt, ich tippe eher darauf das du dir - wobei auch immer - den Stack im Vorfeld mehr oder weniger zerschossen hast (Verwendung nichtinitialisierter Zeiger...).

cu André

Aber das ist ja auch gar nicht mehr mein Problem.

Okay, okay, klassischer Fall von "zu früh gepostet": Ein Aufruf von buffer.clear() bringt die ganze Sache zum funzen. Wüsste jetzt allerdings nicht, was ich da für error flags produziert haben könnte, die beim zweiten Mal eine ordentliche Ausführung verhindern könnten. Aber solange es jetzt geht, soll mir das ja egal sein.

Im Moment bastle ich mir meine ostringstreams zusammen, und will die dann alle der Reihe nach in einen ofstream füttern, um in eine Datei zu schreiben. Was ich da im Moment mache, um vernünftige Ergebnisse zu bekommen, ist:

ostringstream buffer;
// buffer wird irgendwie gefüllt...

ofstream file;
file << buffer.str();

Geht natürlich einwandfrei, sieht aber unnötig umständlich aus. Die Frage wäre aber, ob das nicht irgendwie auch direkt funktioniert? Die beiden Streams sind doch von der selben Klasse (ostream) abgeleitet, da müssten die doch irgendwie auch direkt aneinanderhängbar sein. Leider scheint dabei aber nur die Adresse des buffers geschrieben zu werden, statt des Inhaltes. Muss ich also zwangsweise über den String gehen?

EDIT: Nö, es geht gar nicht. Eingebaut, ausprobiert. Aber alles ab dem einen nach oben vorgeschlagener Art veränderten Aufruf kommt nicht mehr in die Datei.

Wüsste jetzt allerdings nicht, was ich da für error flags produziert haben könnte, die beim zweiten Mal eine ordentliche Ausführung verhindern könnten. Aber solange es jetzt geht, soll mir das ja egal sein.

der stream wurde bis zum ende gelesen, und damit "eof" gesetzt.

es gibt allerdings auch eine einfachere lösung:

istringstream buffer("3.142, 1.414, 2.718");

for (int i = 0; i < 3; i++)
{
   buffer >> theFloats[i];
   buffer.get(); //schlucke ','
}

Geht das schneller? Ich nehm's mal an.

den streampuffer (stream.rdbuf()) zu übergeben ist die schnellste möglichkeit, die es gibt.

Was das andere betrifft, siehe meinen Edit weiter oben. Scheint nicht zu gehen.

was geht nicht? ist die datei geöffnet? noch etwas im stringstream drin? ...?

mach doch einfach einen stringstream daraus, dann wird es funktionieren.