The visual debugger in both Eclipse CDT and Visual C++ let you do things like create breakpoints, step through your program, monitor variable values, even create conditional breakpoints that are triggered when a particular lineof code is executed n number of times or when some particular expression involving variables in the local context of the breakpoint turn true.
My question is, what advantages do you get in using gdb directly through the CLI rather than through an IDE? (like Eclipse/NetBeans which itself uses gdb for C/C++ debugging, but has a nice graphical UI for it.)
Flip it around: what advantage does a "nice graphical UI" give you for what is fundamentally a text processing problem. Except for the most basic stuff (starting, stopping, setting a breakpoint at a line, looking at a variable value) everything you want to do in gdb involves something approximating a query language: set a watchpoint on the 32 bit quantity stored at this address; dump memory from this pointer; call this function (e.g. strstr() on a memory region) and tell me the result.
Watching your code run and hitting a "next" button repeatedly isn't really a good use of the tool.
GDB itself has a -tui option which gives you a nice "gui" style interface in the command line. As to why you would not use any sort of gui interface, I don't think the command line alone gives you any advantage as far as I know.
I'm not sure if CDT and Visual C++ can't do that, but I don't think so: gdb can attach to already running processes. Saved me once from a bug in ruby runtime.
You can use conditional breakpoints and watch expressions in gdb, too. It works how you would expect, not dissimilar to the GUI way.
One advantage is that gdb might be available in more environments.
In general, whatever you are more comfortable with is the better tool. I prefer command-line interfaces for most things, but find it easier to set breakpoints by clicking next to a line of code.
Comments
The visual debugger in both Eclipse CDT and Visual C++ let you do things like create breakpoints, step through your program, monitor variable values, even create conditional breakpoints that are triggered when a particular lineof code is executed n number of times or when some particular expression involving variables in the local context of the breakpoint turn true.
My question is, what advantages do you get in using gdb directly through the CLI rather than through an IDE? (like Eclipse/NetBeans which itself uses gdb for C/C++ debugging, but has a nice graphical UI for it.)
Flip it around: what advantage does a "nice graphical UI" give you for what is fundamentally a text processing problem. Except for the most basic stuff (starting, stopping, setting a breakpoint at a line, looking at a variable value) everything you want to do in gdb involves something approximating a query language: set a watchpoint on the 32 bit quantity stored at this address; dump memory from this pointer; call this function (e.g. strstr() on a memory region) and tell me the result.
Watching your code run and hitting a "next" button repeatedly isn't really a good use of the tool.
> Watching your code run and hitting a "next" button repeatedly isn't really a good use of the tool.
It's really useful to get yourself familiar with someone else's code.
GDB itself has a -tui option which gives you a nice "gui" style interface in the command line. As to why you would not use any sort of gui interface, I don't think the command line alone gives you any advantage as far as I know.
I'm not sure if CDT and Visual C++ can't do that, but I don't think so: gdb can attach to already running processes. Saved me once from a bug in ruby runtime.
The Visual C++ debugger can attach to a running process. I've used that feature to debug server code.
You can use conditional breakpoints and watch expressions in gdb, too. It works how you would expect, not dissimilar to the GUI way.
One advantage is that gdb might be available in more environments.
In general, whatever you are more comfortable with is the better tool. I prefer command-line interfaces for most things, but find it easier to set breakpoints by clicking next to a line of code.