[CoolGuySteve]

Is Visual Studio really the best debugger?

Every time I use it I get really frustrated by the difficulty of entering complex instructions. The GUI is more discoverable but I find myself missing gdb ‘s functions and parser.

However, one thing in gdb that’s become steadily worse is the ability to evaluate STL’s operator[] and the like in optimized code, with the debugger frequently whining about inlining. It’s pretty horrible having to decipher the _m_data or whatever of various implementations.

I’m actually not sure if gcc is not compiling the inlines into the object code (I thought it was required by the standard) or if gdb just can’t find them.

[berkut]

Unfortunately, yes (and I'm a very strong Linux proponent these days), in terms of what it can display and work out in terms of locals and watches automatically. It's the one thing I miss from Windows (and I haven't used it really in 10 years).

I'm also of the opinion that GDB is getting worse in terms of what it shows (or more often won't) these days, especially with regards to >= C++11 - maybe it's just out-of-date python pretty-printers, but on multiple recent linux distro machines, it won't even show the contents of std::string these days without diving inside the structure or using expressions.

[pjmlp]

Yes, given the graphical tooling for multi-core, GPGPU, data visualization, edit-and-continue, mixing Assembly with code (even on .NET), interaction with GUI components on WPF/UWP apps,...

[CoolGuySteve]

That kind of gets to the heart of what I’m saying. These graphical tools are great as long as they do what you need. But they are less composable and customizable than an expression parser.

Like in the article he mentions not being able to see custom data types, but my .gdbinit has a few pretty printers in it for exactly that purpose.

And when you do get something customized in MSVC like a specific PGO build or something, it tends to be tightly coupled to that project. It’s less easy to cut and paste into another project since the primary interface is really a dozen little text fields modifying XML somewhere.

[pjmlp]

VS supports displaying custom types.

Regarding gdb, during the mid-90's I got by calling it from XEmacs, until I discovered DDD.

I got spoiled with Borland debuggers, typing n, s, l, p all the time and drawing structures on paper gets tiring after a while.

[coffeeaddicted]

You can parse expressions inside the "QuickWatch" dialog in VS.

[jcelerier]

At least for the Qt ecosystem, apps like Heaptrack, Hotspot, Gammaray are in my opinion miles better than what VS provides.

[pjmlp]

Have you ever used IntelliTrace in Visual Studio Ultimate?

[uglycoyote]

I can't speak to the comparison with gdb, but as a game developer I have had the misfortune of working with a lot of second rate debuggers that were the only option because they were part of the toolset for that particular game console. Most of these are pieces of software that the console maker would contract out to a smaller company to build custom and provide as part of the development kit, and they would be riddled with bugs, poorly supported, often poorly translated from Japanese (I recently worked with a debugger which had "Go" and "Come" as a couple of the primary menu items, I think those were supposed to mean start and stop), and lacking in important features.

Basically it was such a pain to debug on the actual game console platform that we made a PC build of the game just so that we could have the pleasure of debugging in Visual Studio and avoid having to debug on the console, even though we were not planning to ship on PC. Maintaining a separate PC rendering engine and other platform specific libraries at a fair expense, but it was always worth it in terms of being able to solve problems faster. We had other motivations as well, on some game platforms the tools for linking and building an executable "ROM" could be quite slow, so having a PC build would save quite a bit of turnaround time.

I have always had a very high opinion of Visual Studio's debugger because it has a few features that are invaluable that other debuggers lack:

- "Immediate Mode", a.k.a., the ability to run C++ functions while stopped at a breakpoint. We use this a lot for writing functions which log out a bunch of useful information which would otherwise be tricky or time consuming to find via the debugger's usual interface (watch window, or whatever). In particular, we encode all our strings in the game as 32-byte hashes but in debug modes we keep a u32-->string lookup table around, and calling functions in the immediate window is invaluable for getting identifying information from out of those string-hashes.

- Data Breakpoints, i.e. stop when a particular memory address is written to. Critical for debugging "memory stomp" bugs such as array-overflow issues or writes to dangling pointers.

- Custom "visualization". Visual Studio's debugger has an XML language called .natvis which allows you to define a custom way to pretty-print specific types. Basically the equivalent of defining a custom "ToString" in a language like C#. The .natvis language is kind of annoying to use, but without it certain data types would be a real pain to look at in the debugger. (e.g. rather than using pointers everywhere, we have a safer Handle type which is essentially a lookup into a table that has a pointer. These indirections would be a pain to follow manually in the debugger, but .natvis allows us to present the target object in the debugger automatically, so that it is as easy as following a normal pointer)

- Automation. There's a fairly rich automation API ("ENVDTE") which allows you to drive the debugger from outside tools. I'm currently using this with Python to provide a convenient way for non-technical people (e.g. QA testers) to bundle up and send all of the relevant details from a crash to other members of the team. (e.g. callstack with all the locals, and contents of log)