I was really hoping for a new GDB video from Greg Law. This is exactly the kind of video I was expecting: here's what you can do and how you can do it, the practical approach video. Thanks!
[Finished] As a beginner to C++, I found this video to be somewhat challenging. Although the speaker introduced several helpful commands like `gdb` and `rr`, in the examples of the video they produced too much output on the console for me to keep up with. As a result, I struggled to follow the speaker's actions at times. To help other beginners like myself, it might be useful for the author to slow down the pace of the video and add more annotations to make it easier to understand.
Interesting talk but I think I'll stick to IDEs like VS Code (which I think use gdb under the hood). Simply no way I can remember all this, and I don't want to think about my debugger text commands while I'm supposed to be thinking about the issue at hand. Same reason why I gave up on vim. Valgrind's and other dynamic or static analyzers are a great addition though.
So.. what does this presentation have to do with C++ exactly? (apart from the title, and the one page he mentions pretty printers) IMO, this was 99,9% C and 0,1% C++ at best.
I almost never use debugger in C++ after I realized you actually have to follow OOP rules. Most important of them in C++ are ownership, constructor/destructor -rule and not using raw arrays. But you can already guess what 99% of programmers don't follow.
I hope the intent of this comment wasn't to invalidate the talk. Some programs need things like raw arrays and avoid OOP for performance reasons. And if you value easy and safe code over complex and optimized code, maybe another safer language might be more appropriate.
The problem is the current state of software engineering with release often, release early. This makes it almost impossible to maintain software patches. Also customers for whatever reason always want to use the latest versions. And ignorance in the language/compiler team about the importance of debugging is another serious factor. Most people don't realize how important it is. I once maintained a ruby debugger (it would still be the best, 100 times faster then Komodo/Rubymine) but i had to give up.
I was really hoping for a new GDB video from Greg Law.
This is exactly the kind of video I was expecting: here's what you can do and how you can do it, the practical approach video.
Thanks!
[Finished]
As a beginner to C++, I found this video to be somewhat challenging. Although the speaker introduced several helpful commands like `gdb` and `rr`, in the examples of the video they produced too much output on the console for me to keep up with. As a result, I struggled to follow the speaker's actions at times. To help other beginners like myself, it might be useful for the author to slow down the pace of the video and add more annotations to make it easier to understand.
I prefer cgdb to gdb TUI mode. It has syntax highlighting and vim-like keybindings. And I find it's display doesn't get screwed up often like gdb TUI.
Thanks for the advice.
Excellent talk! Tons of useful hands on information.
Can someone share the link to the presentation download. Can't find it on the github link.
Seems the slide is missing from the git repo, is there a link to the slide of this presentation?
Very nice! Please do one for Windows!
The fact that printf is ever the right tool.....is a pretty damning statement for the current state of debugging tools.
Interesting talk but I think I'll stick to IDEs like VS Code (which I think use gdb under the hood). Simply no way I can remember all this, and I don't want to think about my debugger text commands while I'm supposed to be thinking about the issue at hand. Same reason why I gave up on vim. Valgrind's and other dynamic or static analyzers are a great addition though.
fantastic, thank you.
`signal SIGINT` sends the signal from gdb to the process being debugged.
Super helpful!
There's always Qira (GeoHot's timeless debugger), which makes binary run time analysis so much easier to deal with when compared to gdb.
So.. what does this presentation have to do with C++ exactly? (apart from the title, and the one page he mentions pretty printers) IMO, this was 99,9% C and 0,1% C++ at best.
Do you think gdb is solely a c debugger? 🤔
The description makes it clear what the presentation is about.
fourth !
I almost never use debugger in C++ after I realized you actually have to follow OOP rules. Most important of them in C++ are ownership, constructor/destructor -rule and not using raw arrays. But you can already guess what 99% of programmers don't follow.
I hope the intent of this comment wasn't to invalidate the talk. Some programs need things like raw arrays and avoid OOP for performance reasons. And if you value easy and safe code over complex and optimized code, maybe another safer language might be more appropriate.
GDB is terrible, I wish FLOSS people were not so much against charging/paying money for SW so that somebody would make a decent debugger...
The problem is the current state of software engineering with release often, release early. This makes it almost impossible to maintain software patches. Also customers for whatever reason always want to use the latest versions. And ignorance in the language/compiler team about the importance of debugging is another serious factor. Most people don't realize how important it is.
I once maintained a ruby debugger (it would still be the best, 100 times faster then Komodo/Rubymine) but i had to give up.
try gdbui or pay for something like clion
First
Patrick TAYLOR wow guys look, an idiot below a cppcon video! :)