Redirect Debug/Warning/... to OutputDebugString on Windows about corrade HOT 8 OPEN

OutputDebugString isn't just for GUI apps, it works for console apps too. You can think of Windows apps as always having two different output streams - standard out and debug out - and one of them is only relevant while you have a debugger attached. Debugging-related messages should always go to OutputDebugString and normal input/output (such as piping between parent and child process) should be unaffected by it. Perhaps it should be configurable?

from corrade.

IsDebuggerPresent()

Currently testing in vs2019 - seems to work fine with RelWithDebInfo, and doesn't return true if no debugger attached.

from corrade.

So it means ... if I run with F5, it says true, if I run with Ctrl-F5, it says false? In both cases I'd like the output to be shown.

from corrade.

if I run with F5, it says true, if I run with Ctrl-F5, it says false

Yup, I think that's exactly the case with IsDebuggerPresent() (you could of course do Ctrl-F5 and then reattach the debugger, but I don't think that's what you're implying..?)

from corrade.

I thought I could use IsDebuggerPresent() to check if the app is being run from within Visual Studio. Because I imagine, if the app is run outside of the IDE, people would want the debug messages to be again in the standard output (or not?).

Well, Windows is not my native system, so I'm just guessing -- but I imagine everything sent to OutputDebugString is lost when you don't have the VS debugger attached? Or does it go somewhere else? System log?

from corrade.

I tried here with MinGW-w64 GCC/GDB on Windows, using both CLion and the MSYS2 build of Qt Creator (I don't use VS because it can't be used with GCC and because it's really bloated).

IsDebuggerPresent() returns false when run normally through the IDE, and true when run with GDB attached. This happens both in Debug and Release (I don't use the other CMake build types).

Notes:

• Qt Creator manages to grab the app's output anyway, I didn't need to do anything over there for some reason.
• However, in CLion, I had to open its settings registry (the equivalent of Firefox' about:config screen), and switch run.processes.with.pty to false to see output when running an app normally (output when debugging worked out of the box).

from corrade.

Note that you can just always send output to OutputDebugString and, when the application is running outside of Visual Studio, see it using the Sysinternals tool DebugView - see the download page. It was developed outside Microsoft but Microsoft acquired them. I've been using it for years - it's got some handy redirection and filtering capabilities, but you can also run it from the CMD CLI and redirect its output to a file.

from corrade.

OutputDebugString() is apparently implemented via exceptions, so I imagine using it always could have some bad perf implications compared to the regular stdout.

OTOH, thanks to that tweet now I probably know how to catch it even without VS debugger or DebugView attached :)

from corrade.