| News | Features | Interviews |
| Blog | Contact | Editorials |
| Learning C with GDB |
| By Thom Holwerda, submitted by MOS6510 on 2012-08-28 19:20:35 |
| "Coming from a background in higher-level languages like Ruby, Scheme, or Haskell, learning C can be challenging. In addition to having to wrestle with C's lower-level features like manual memory management and pointers, you have to make do without a REPL. Once you get used to exploratory programming in a REPL, having to deal with the write-compile-run loop is a bit of a bummer. It occurred to me recently that I could use gdb as a pseudo-REPL for C. I've been experimenting with using gdb as a tool for learning C, rather than merely debugging C, and it's a lot of fun. My goal in this post is to show you that gdb is a great tool for learning C. I'll introduce you to a few of my favorite gdb commands, and then I'll demonstrate how you can use gdb to understand a notoriously tricky part of C: the difference between arrays and pointers." |
|
| RE: Not REPL |
| By kwan_e on 2012-08-29 08:38:32 |
| That's why he uses the term pseudo-REPL. |
 - Score: 3 |
| RE[2]: Debuggers |
| By kwan_e on 2012-08-29 08:45:14 |
|
> especially if you're dealing with segfault or memory allocation issues which are pretty damn hard to find with print. Of course. Importantly for me though is debugging by printing does the important thing of making you review design in the process. You're actively testing your own assumptions of how the design is working. I find that people who use debuggers most of the time tend to fix problems locally rather than wondering if a slight alteration to a design would eliminate whole classes of defects. This makes it even better for learning a new language. |
| - Score: 2 |
| REPL - a key to success |
| By dnebdal on 2012-08-29 09:20:59 |
|
> Yep thats called experience. At some point you discover that you have a fancy algorithm or idea in your head, you sit down., write a program, compile, run , and discover that it works perfectly the first time. Thats great feeling! And even after some years of working with this, having a program work on the first try is still rare enough that it feels like a victory every time it happens. :D |
| - Score: 2 |
| RE[2]: Not REPL |
| By ndrw on 2012-08-29 10:21:43 |
| It may look like "pseudo-REPL" but it just isn't one. Not even "pseudo". The whole point of REPL is that you write your program in it, and you get an incremental feedback as you do it. Think of it as of an IDE on steroids (one that really understands and executes your code). You simply can't do that in Gdb at all. Yes, you can analyze the program, but if you want to make any changes you have to go back to your editor and build system. |
| - Score: 1 |
| RE[3]: Not REPL |
| By kwan_e on 2012-08-29 11:29:21 |
|
> It may look like "pseudo-REPL" but it just isn't one. Not even "pseudo". The whole point of REPL is that you write your program in it, and you get an incremental feedback as you do it. Think of it as of an IDE on steroids (one that really understands and executes your code). You simply can't do that in Gdb at all. Yes, you can analyze the program, but if you want to make any changes you have to go back to your editor and build system. That's what makes it pseudo. Why don't you read the article? He's not proposing to write programs with it. He's proposing using GDB, in analyzing the program, to simulate the feedback you can get from an REPL language. Not that it is one. Therefore: PSEUDO. |
| - Score: 3 |
| RE[4]: Not REPL |
| By ndrw on 2012-08-29 11:53:10 |
|
If you can't type C code in it and have it evaluated then it isn't a REPL. It is as simple as that. Yes, it is a REPL for a Gdb command language, which happens to mimic some primitive C operations (arithmetic, pointer dereferencing). But Gdb is not C. I do agree that Gdb is a useful tool for analyzing programs (that's what I wrote in the first comment) but it just isn't a REPL for C, for any value of "pseudo". |
| - Score: 1 |
| RE[5]: Not REPL |
| By kwan_e on 2012-08-29 11:57:38 |
|
> If you can't type C code in it and have it evaluated then it isn't a REPL. It is as simple as that. That's why he didn't call it an REPL. He called it a PSEUDO REPL. Are you retarded? PSEUDO. PSEUDO. PSEUDO. |
| - Score: 3 |
| RE[6]: Not REPL |
| By MOS6510 on 2012-08-29 12:04:22 |
|
Call it what you want, it's still not REPL. (okay, just trolling) |
| - Score: 2 |
| RE: Debuggers |
| By ephracis on 2012-08-29 20:19:40 |
|
I like using breakpoints which let me inspect variables by just hovering my mouse over the variable's name anywhere in the code. Then I can jump up and down the call stack and see how my execution has been moving around the code. A really nice complement to log output. |
| - Score: 2 |
| RE: C |
| By ephracis on 2012-08-29 20:21:30 |
| Agreed. Pointers are really easy if you just read about them in any book or even on Wikipedia. But trying to understand pointers by poking around in a debugger might take a while. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |