spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

1000 bis 2000 Ausgaben pro Sekunde dürften ohnehin nicht mehr übersichtlich sein. Ich kann mich Hafernuss nur anschliessen.

Ansonsten wäre std::stringstream eine Alternative. Wobei ich glaube, dass die Streams darauf ausgelegt sind, regelmässig geleert zu werden. Möglicherweise fährst du mit einem eigenen Riesen-Puffer besser.

Du kannst Streams nicht kopieren oder zuweisen.

Nimm doch für den Puffer std::string. Hol dir mit reserve() etwas Speicher und verwende append() oder operator+=, um Strings anzuhängen. Zur Umwandlung anderer Typen kannst du std::stringstream benutzen. Wenn du mit std::string Probleme wegen Reallokationen bekommst (was ich bezweifle), wäre auch std::deque<char> eine Möglichkeit.

Nach wie vor ist aber die Frage offen, wie sinnvoll unsere Ratschläge bei deiner Datenmenge sind. Warum genau musst du so viel loggen und wie willst du die Ausgabe nachher untersuchen?

Hast du schonmal dran gedacht einen Debugger zu benutzen?

Debug-Ausgaben sind wahnsinnig praktisch. Manchmal sind sie viel besser als ein Debugger, vor allem wenn man nicht nur einen Zustand, sondern den zeitlichen Verlauf untersuchen möchte. Nichtsdestotrotz verstehe ich nach wie vor nicht, wie aus so vielen Ausgaben nützliche Informationen geholt werden können.

Abgesehen davon deuten nicht deterministische Abstürze sehr stark auf undefiniertes Verhalten hin, was wiederum ein guter Indikator dafür ist, dass zu wenig abstrahierende Sprachmittel eingesetzt worden sind. Also viele Operationen direkt mit Arrays, manueller Speicherverwaltung, etc. Sowas gilt es zu vermeiden. Seit ich das tue, habe ich fast nur noch Logikfehler in meinen Programmen.

Zitat von »Nexus«

Debug-Ausgaben sind wahnsinnig praktisch. Manchmal sind sie viel besser als ein Debugger, vor allem wenn man nicht nur einen Zustand, sondern den zeitlichen Verlauf untersuchen möchte.

Natürlich. Da sein Problem ja aber offenbar ein Absturz ist schien mir die Frage naheliegend da ein Debugger ja eben gerade in so einem Fall an Ort und Stelle den Fehler aufzeigt...

Mit " try{}catch(exception){"Fehlermeldung"} " findet man den fehler sehr schnell mit dem debugger. Vielleicht solltest du dir das mal näher anschauen.