Deutsch
One of my old computer science professors, back in the days, used to say, if you use a debugger while you are writing your code, you are a bad programmer. My, oh my. What an idiot. It makes perfect sense to utilize a debugger as you proceed in completing your program. It’s a simple variant of divide and conquer. Let’s make sure one part does work, before we move on to the next. So, you see, I really value my debugger.
Many small tools I write are simple console applications. I do like graphical user interfaces a lot. And I prefer a graphical user interface over a command line interface any time. But for some small tools, especially ones which do not even require any interaction, setting up a graphical user interface is just too much work. So, even so it really is very old-school, console applications are often the right choice.
This brings us to developing console applications and utilizing the debugger. Visual Studio has a very nice feature for this scenario, when working with c++: it keeps the console window open and reuses it. At first this might seem useless. I know a lot of people which just close the window every time their application stops. But there is a clear and huge benefit from this function: since the console window stays open, you can inspect you application’s output for as long as you like without having to keep the debugger attached or starting your application in a separate console. This actually is really handy.
For csharp console applications, however, this feature does not exist. I really do not know why. And, I hope the Microsoft will deliver this feature soon for csharp applications as well. But for now, csharp has this horrible behavior that the console window closes as soon as the application exits. And this brings us back into the past, where we need some mechanism to keep the window open. One possibility is to utilize the debugger, which is attached anyway, to pause the application. I don’t want to do this using “normal” break points, as I use break points to do actual debugging. Meaning, I often delete all break points, and then only set those I need. Having to take care for some “special” break points would be a pain in the … well, you know.
Luckily, we can break the debugger by code. Whipping up some utility class, I got this here:
static class DebugHelper
{
[Conditional("DEBUG"), MethodImpl(MethodImplOptions.AggressiveInlining), DebuggerHidden]
static public void Break()
{
bool launch;
var env = Environment.GetEnvironmentVariable("LAUNCH_DEBUGGER_IF_NOT_ATTACHED");
if (!bool.TryParse(env, out launch))
launch = false;
if (launch || Debugger.IsAttached)
{
if (Debugger.IsAttached || Debugger.Launch())
Debugger.Break();
}
}
}
Now, I can just call DebugHelper.Break(); anywhere I like.
They are removed in release builds. And the aggressive optimization removes the helper function from the stack, so that the debugger always breaks at the call of my helper function, and not within.
For now, this is handy. And, I really hope, that in the near future this will be obsolete.
I am a visual guy. That means I like all kinds of visual representations of abstract data. And so, of course, I also like all those fancy little badges available all over the internet. It is only a logical conclusion that I use those as well.
glm
teamcity-gtest-streamer
I will not continue with my game idea project “SpringerJagd”.
As can be read on the internet: HtmlAgilityPack is not for beautiful, aka human readable, html files.
And here is another Nuget package:
