Hi,

ich erzeuge unter Windows via AllocConsole() eine eigene Console und leite stdout und stderr dahin um - das klappt wunderbar.

Nur leider gibt es schon einigen Output bevor die Console erzeugt wurde, gibt da irgendeine Möglichkeit da noch nachträglich dran zu kommen und das auch in der Console auszugeben?

Aya~

Nachträglich wohl nicht, nein. Aber du könntest natürlich eine eigene Log-Klasse schreiben die die Ausgabe zwischenspeichert bis die Console verfügbar ist. Vom Prinzip reicht ja ein std::stringstream

_________________
Yeah!

Das wäre meine Alternative, hatte nur gehofft das es auch so geht

...und die Möglichkeit AllocConsole vor allem anderen aufzurufen hast Du nicht?

Leider nein, da selbst der Buffer der Windows Konsole stark begrenzt ist, würde das auch keine Lösung sein.
Leg dir ein eigenen Logger zu und dann kannst du auch deine Backends dran pappen wie du willst.
Ich z.B. habe an mein Logger ein Crashreport, Konsole, SysLog und HTTP MiniServer dran gehangen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Worauf genau bezieht sich jetzt Dein Nein? Wie groß der Buffer (welcher auf immer) spielt bei der Frage doch keine Rolle. Falls doch, da gibt es allerhand Funktionen (http://msdn.microsoft.com/en-us/library/ms682073%28v=vs.85%29.aspx) mit denen man die Größe anpassen könnte.

Kläre mich bitte auf, falls ich mich irre.

Ist doch offensichtlich. Wenn der Buffer sicher als größer bekannt wäre, hätte man versuchen können, die Daten aus dem Buffer der alten Konsole zurückzuholen. Das ist aber keine Option, da man, wenn man den Buffer rechtzeitig vergrößern könnte, wahrscheinlich auch die neue Konsole rechtzeitig allokieren könnte. Abgesehen davon, dass es schwierig wird, die benötigte Buffergröße vorher zu kennen.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Nein bezog sich auf die erste frage von Aya.
Man kann den Buffer natürlich ändern aber das ist nur eine verschiebung des Problems nach hinten, es existiert aber weiterhin.
Daher ist es besser ein anderen Weg zu gehen. Ein eigener Logger bringt viele Vorteile.
-Loglevel
-optimierbare Formatierbarkeit
-eigene buffering methoden
-mehrere Log ziele parallel möglich
-message filter

Windows Konsolen sind recht gewöhnungsbedürftig. Die haben ein sehr niedrigen Ausgabedurchsatz und kosten recht viel CPU zeit.
Den Ausgabedurchsatz kann man oft ignorieren, da keiner so schnell lesen kann aber es macht ja auch die Anwendung langsamer, da diese warten muss bis der Blocking Konsolen output durch ist. Gerade bei OpenGL ist das ein Bottleneck.
Um dies zu umgehen, kann man die Loginfos sammeln und dann ausgeben, wenn eine gewisse Zeit oder Größe überschritten ist(wie es stl bei Datein macht).
Dieses interval Ausgabe ermöglicht der Windows Konsole ungeahnte log Geschwindigkeiten und blockt die App nicht permanent.
Ich hab auch schon Code gesehen, da nutzte man ein async. logger, also ein extra thread und eine queue. Der Thread arbeitet die queue ab und damit ist die log api async. . Dies macht in meinen Augen aber wirklich nur Sinn, wenn man die log formatierung dem thread überlässt.

Auf Arbeit loggen wir ne menge und dies ist auch die teuerste Operation bei unserem ganzem Server und Client system. Es sind 2 Probleme, einmal das blocking während auf die Konsole geschrieben wird und unser aktuelles Problem, die Formatierung eines Strings.
So eine Stringformatierung ist trotz jeglicher Optimierung sehr sehr sehr teuer, mehrere new/delete call's, einige memset/memcopy, destructor/constructor aufrufe und ein bisschen kleinkram ops. . Also alles im allem ziemlich teuer und während der Zeit kann natürlich der jeweilige Thread nicht weiter laufen sondern macht die Formatierung. Dies ist bei Netzwerk, Echtzeitgrafik ein wirkliches Problem und sollte man vor haben für diese Systeme ein logger zu schreiben, sollte man dies von vorn herein bedenken. Wir haben es nicht bedacht und werden irgendwann nach der Release es nachbauen müssen und leben aktuell mit der höheren Latenz im Netzwerkverkehr.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Em, Nein es war nicht offensichtlich. Und so recht verstehe ich das Problem nicht so ganz. Wenn man mal Buffergröße und performance der Standard Windows Console weglässt, ich habe doch die Möglichkeit sie zu nutzen (und alle anderen libs, units, Klassen, was weiß ich), sobald ich sie "allokiert" habe. Und wenn ich das als _allererstes_ mache dann ginge mir doch auch kein Eintrag ins stdout verloren.

Beispiel: