[snarfy]

Calling Visual Studio 'less powerful' than GDB is telling.

When you have a bug that doesn't happen until hours into your program execution, being able to set a breakpoint, edit-and-continue, and set-next-statement are worth their weight in gold. You can solve in the moment what would take literally days, even weeks using a logging approach.

Sure they both have their place but having a debugger is indispensable, and Visual Studio's debugger is the undisputed king.

[turtledragonfly]

> undisputed king

Well, I personally do agree it's a better, more solid overall product. And also agreed that edit-and-continue in some highly stateful situation can be ::chef's kiss::

But I think there is room to dispute its kingliness (:

For instance, scripting GDB with Python is quite nice, on occasion.

Actually, just on Windows, WinDBG has some killer-feature functionality of its own.

Or back with GDB, take, for example, this classic post by Jonathan Blow, where there is some good back-n-forth discussion about GDB vs VStudio, with varying opinions:

* https://news.ycombinator.com/item?id=5125078

Plenty of disputers out there, I daresay.

[MaulingMonkey]

> edit-and-continue

Breaks on enough codebases for me to not be in the habit of relying on it.

My own "killer feature" of VS debugging is being able to open up a crash dump, have VS auto-download matching pdbs from a symbol server, and auto-view the correct source file version/revision thanks to source indexing - without checking out by hand and turning my build stale. Killer ergonomics.

Sometimes I'll resort to windbg/cdb for memory pattern searches, automation, untangling wow-mangled crashdumps, etc. but VS itself is a nice first resort.

[sam_bristow]

I've been wanting that symbol server style workflow for GDB for years. It looks like all the parts are there but I haven't found anyone who has plumbed them together into a complete system yet.