3 ms·

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

by snarfy 4y ago

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 4y ago
> 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 https://news.ycombinator.com/item?id=5125078 Plenty of disputers out there, I daresay.
MaulingMonkey 4y ago
> 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 4y ago
  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.

by snarfy 4y ago

turtledragonfly 4y ago

> 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 https://news.ycombinator.com/item?id=5125078 Plenty of disputers out there, I daresay.

MaulingMonkey 4y ago

> 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 4y ago
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.