[green7ea]

I've seen this best debugger thing come up a few times before. I'm currently working with windows on a project right now and I'm finding the VS debugger more limited than GDB. With GDB I can create scripts which analyse and print complex memory layouts very quickly and efficiently. With valgrind, I can find memory leaks and other unwanted behaviors. With gcc's dump-tree family of options, I can see how my code is turned into assembly. I haven't been able to do these things well under VS and I think it comes down to preference and habit. So my question is, what makes VS's debugger the "best debugger", what am I missing?

[forgottenpass]

So my question is, what makes VS's debugger the "best debugger", what am I missing?

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.

[tracker1]

I have to agree here... When I've had to fall into using a debugger pragmatically VS integration is probably the best experience I've had (eclipse, intellij etc don't compare).

That said, having been working a lot with node/iojs modules the past few years, I find that experience even better. I'm pretty sure others who are using scripted languages with a REPL can probably state the same. Running in an environment where you can jump in anywhere, call a particular script and replace variables for testing is a powerful experience.

I don't mean to start a scripted vs. compiled war... they both have their place. Just mentioning because people will reach for a compiler for things that could be much simpler with a scripted environment more often than not.

[HanyouHottie]

Your language doesn't need to be interpreted to have a REPL. Haskell has a REPL. The Immediate window in Visual Studio is essentially a REPL for all .NET languages (so you get that and the VS debugger together, win/win).

[lloeki]

> having been working a lot with node/iojs modules the past few years, I find that experience even better. I'm pretty sure others who are using scripted languages with a REPL can probably state the same

In Ruby-land, the pry gem called on a binding (binding.pry) is a godsend.

[maxlybbert]

Ease of use and discoverability.

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.

[berkut]

I use Linux (and GDB) at work and home for C++ stuff, and unfortunately, GDB (even with pretty printers configured correctly) often doesn't work correctly for things like templated params, templated classes.

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.

[to3m]

(Alt+8 gets you an assembly language view in VS. Right click to get the context menu, then select "show source". Similarly, press Alt+5 for a registers window, and right click to select register set(s). (This particular bit of UI isn't exactly amazing, but it does basically work.) Or, for getting an assembly language listing from a build, go to the project properties and select listing file format "Assembly, machine code and source". The format is quite readable.)

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.)

[krig]

For me, it's two things in particular: 1. Reliability - I have had so many issues with debugging especially C++ using GDB where GDB will get completely confused, whereas Visual Studio is able to do a decent job even on heavily optimized code. However, I understand that GDB has improved in this aspect. 2. User interface. Having the debugger also be a visual code editor is really nice. It's difficult to articulate just how nice it is to someone used to a command-line based interface. Being able to create analytic scripts is nice. With VS I've rarely felt the need, it's basic tools are good enough. They are terrible, don't get me wrong, but they are better than any interfaces available for GDB.