93 ms·

The goal is not to stick to a particular style- it's to use the best tools for the job. why settle for gdb when there is VS Which is light years ahead. just lik

by fxfan 8y ago

The goal is not to stick to a particular style- it's to use the best tools for the job. why settle for gdb when there is VS Which is light years ahead. just like why use vscode when there is vim which is light speed faster?

xemdetia 8y ago
I made no indication of 'settling for gdb,' you can use gdb in plenty of places where Visual Studio doesn't make any sense at all and provided some examples. If you haven't looked at the GDB TUI you might be surprised on how competent it is and having a well supported python interface to automate or enhance specific debugging for a project is pretty great. GDB hooking a runaway process in production that's using up a ton of resources is also much easier to do from shell than trying to coerce Visual Studio to do it. It is also possible that the kind of things you are debugging also don't fit Visual Studio and better served by tools and things like WinDbg. This comes up when you are doing kernel driver debugging or really having to work with lots of symbol server shenanigans when you have kernel dumps from all sorts of random versions of Windows. There's a lot of tools out there, and Visual Studio is often not the best tool for the job even for debugging. Settling for Visual Studio has its own set of compromises. As I mentioned for gamedev the Visual Studio experience is the current de facto standard for engines like unreal and as far as I am aware many of the SDK's for consoles, and all of the asset creation tooling from Maya, 3dsmax, etc. There are just other things that exist in the world than the primary pipeline that Visual Studio services with fantastic tech.
btschaegg 8y ago
While I agree on the "pick the right tool for the job" part, your comment makes me suspect that you have not had a look at GDB for very long (or at all). I have to use the VS debugger at my workplace, and even as someone who has merely dabbled in GDB a bit, I recognize that it's so far out of VS' league, it isn't even funny.

by fxfan 8y ago

xemdetia 8y ago

I made no indication of 'settling for gdb,' you can use gdb in plenty of places where Visual Studio doesn't make any sense at all and provided some examples. If you haven't looked at the GDB TUI you might be surprised on how competent it is and having a well supported python interface to automate or enhance specific debugging for a project is pretty great. GDB hooking a runaway process in production that's using up a ton of resources is also much easier to do from shell than trying to coerce Visual Studio to do it. It is also possible that the kind of things you are debugging also don't fit Visual Studio and better served by tools and things like WinDbg. This comes up when you are doing kernel driver debugging or really having to work with lots of symbol server shenanigans when you have kernel dumps from all sorts of random versions of Windows. There's a lot of tools out there, and Visual Studio is often not the best tool for the job even for debugging. Settling for Visual Studio has its own set of compromises. As I mentioned for gamedev the Visual Studio experience is the current de facto standard for engines like unreal and as far as I am aware many of the SDK's for consoles, and all of the asset creation tooling from Maya, 3dsmax, etc. There are just other things that exist in the world than the primary pipeline that Visual Studio services with fantastic tech.

btschaegg 8y ago

While I agree on the "pick the right tool for the job" part, your comment makes me suspect that you have not had a look at GDB for very long (or at all). I have to use the VS debugger at my workplace, and even as someone who has merely dabbled in GDB a bit, I recognize that it's so far out of VS' league, it isn't even funny.