Open Sourcing Visual Studio’s GDB/LLDB Debug Engine

For people accustomed to IDEs, the fact that they don't have to remember "n" means "next," "s" means "step into," "info breakpoints" will say which breakpoints you've set, etc. is a big deal. Yes, you can use DDD for that, but frankly, it doesn't look as nice.

Additionally, if you want to see what value a variable has, simply hover over it with the mouse pointer. This works for ints, but it also works for std::vector<std::map<int, std::string> >. You can get the same functionality in GDB, but it takes a little work to set it up.

It's not (just) features, it's the interface to those features. The possibility cap may be lower for you, but that doesn't matter to people who just want an approachable interface to step through their code.

This is the part where I'm an elitist asshole: There are developers that program by spending all day, every day in the debugger. They're almost never going to do anything fancy, they just want an easy way to fix their code. Command line gdb is too much effort to learn, and of the IDEs that hook into debuggers, VS does it the best.

Things I quite like about it:

- no grammar to the command set, just keypresses, and no need to press Return. gdb drives me nuts with its command line... feels like trying to count while somebody shouts random numbers in my ear. I'd probably get on better with a command-line driven version of Photoshop than I do with command-line controlled debuggers

- passable support for mixed assembly language/source code debugging (same step commands in all cases)

- dockable UI that's satisfactorily configurable and updates as you work, so you can see a lot of stuff at once. I find the gdb text-based UI like trying to look through a telescope the wrong way, and it's even worse if you go for the line-by-line TTY mode

- it displays code using the normal VS editor, so you can use the code browsing functionality to look around the code as you work

There's plenty of scope for improvement, so while it does a reasonable job, I'm maybe not sure about "best". But... I don't appear to be unique in preferring it to gdb. So if we're going for some kind of democratic vote, then maybe an argument could be made ;)

But overall, the main thing I like about the VS debugger is that it's integrated quite well into the VS workflow. When you run your project in VS, you run it under the debugger. You have other options, it's true - but running under the debugger is the most obvious one, so that's what you do. There are times where you need rather complicated stuff doing, and VS is sadly lacking in that regard. But most of the time, when your code fucks up, the VS debugger provides enough to let you figure the problem out, and your code is already running under it, so there you go.

(I never found a way to get gdb working quite so well - it starts out with your process stopped, for example, so you have to type "run" to get it going. And I never figured out any way to stop your process without being dumped back to the gdb prompt, like Shift+F5 in Visual Studio. If I actually liked working in gdb, I'd probably just get over this, and/or put the time in to figure out how to fix it. But... I don't.)

Sometimes GDB won't show locals properly, and just shows <optimized_out> even though it's an -O0 -g build.

Also, GDB can get really slow with large binaries with loads of symbols when you have pretty printers installed, even to step through stuff. VS's debugger copes with the same code, and displays everything.

I'm also not sure if you can execute Java 8 lambda expressions in the watch window while debugging.