[solutionyogi]

I personally don't use debugger that much but whenever I have used it, I have always been amazed at VS's debugger capability. I don't think I am exaggerating when I say that VS has the best debugger across all languages/platforms. I think this is a GREAT news for all the developers.

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

[stinos]

VS has the best debugger

Yes and no :P Afaik gdb can for particular languages do everything the VS debugger can do, even more (or so I heard once), but the major and utterly important difference is the fact the VS debugger comes with the IDE and the 'I' in the word makes it so much easier to use than anything else out there that usually you can get a lot done with it in a much shorter timespan than with other debuggers. And as such gives people the right to call it the best debugger, imo.

[yoklov]

Still takes a lot less time to use VS than to use the XCode debugger IMO. Having to expand anon struct/union members makes debugging in some codebases a real pain.

[beached_whale]

Not sure if available in XCode or GDB, but the ability to tell VS debugger how to display custom structures is very useful

[josteink]

> VS has the best debugger

Not to nitpick or disregard the rest of your comment (VS has a really good debugger), but "best" always required qualifying.

Best in what cases? Best in what way?

There are times when the "best" debugger available without a doubt is WinDbg, with it being archaic, oldfashioned, command-line based, completely un-automated and all that fully accounted for.

Why? Because I can copy the 500KB exe-file into a production environment, run it there and debug issues found nowhere else.

And obviously you're not going to install VS on your production-server, and if you did, those builds are release-builds anyway, without debug-assistance or PDBs, so the VS-debugger would be handicapped anyway.

So yeah. Just a slight nit-pick that "best" always has to be qualified.

[plorkyeran]

VS can debug processes on remote machines with only a small helper process running on that machine, and while you shouldn't deploy PDBs onto your production servers, there's no reason not to generate them for your release builds.

[deng]

http://en.wikipedia.org/wiki/Gdbserver

Visual Studio misses features like Python scripting, which for instance in gdb allows you to define pretty printers for your objects, which is immensely useful for complex data structures. The VS debugger also does not have a proper MI, at least I never heard of one. The only thing I miss from gdb is "edit and continue", which I admit is pretty cool.

[plorkyeran]

You've been able to define custom debug visualizers in VC++ for a very long time, although until 2012 it was basically undocumented. I do prefer gdb's choice of python over VS's custom xml-based stuff for defining them, though -- VS's is slightly easier for the trivial cases, but it's usually the complex cases where custom visualizers are more than just a minor convenience.

[josteink]

> VS can debug processes on remote machines with only a small helper process running on that machine

You first please :)

I've tried doing that several times and always ended up giving up. If it's not firewalling, its UAC or cross domain trust issues, or DCOM configuration, or process permissions and probably 200 other things which has failed on me in the past.

It only works in the most trivial of configurations. Back in the real world I've only been able to use it once or twice, non-repeatably.

[plorkyeran]

I've never had it be particularly difficult. It does generally require a VPN since forwarding DCOM over ssh is challenging.

[MichaelGG]

>while you shouldn't deploy PDBs onto your production servers

Why? I do it all the time and getting line numbers in the exception logging seems like a nice bonus.

[vbcr]

I have debugged a C# application in VS and a Java application in IntelliJ and in Eclipse. I did not see any debugging features in VS that can claim its superiority over the others. May be I have not used all the features that were available.

Are there any features in VS debugger that are better or non-existent in Java IDEs?

[Locke1689]

Unless you buy JRebel, VS supports a lot more Edit-and-Continue (JVM hot code swap) operations.

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

[mtVessel]

I haven't used IntelliJ, but "Set Next Statement" was what I missed most using Eclipse.

[ygra]

IntelliJ doesn't seem to have it either, which is a pity. It happens quite often that I accidentally step over a line that does something I wanted to step into. In VS, if I know that that line doesn't have any bad side effects when executed twice, I can just pull the instruction pointer (the yellow arrow) back up and step into the line this time.

Another thing I frequently miss in other debuggers is being able to place break-points on statements, not just lines, e.g. the individual parts in a for loop header.

[rasur]

>I don't think I am exaggerating when I say that VS has the best debugger across all languages/platforms.

Have you used any of the debuggers one finds in Smalltalk environments, out of interest?

EDIT: typo

[omtose]

You cannot step back with VS's debugger, can you?

[WDCDev]

You can. I just drag the arrow that appears on broken execution "upwards" to a previous line of code. There might be another way to do it.

[Lawtonfogle]

Does this undo previous commands or does it just rerun code?

[to3m]

Neither - it changes the program counter, ready for the next operation. It's not terribly cunning, but it's sometimes useful.