Submitted by “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.”
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.
That’s why it’s worthy to learn Forth – especially, if you still got your C-64; it’s too “weak” to use C (yes, there is “Power C” for C-64, but it’s somewhat limited) – but it’s strong enough for Forth! My recommendation would be Blazin’ Forth or Super-Forth 64. For Linux/Windows G-Forth could be probably the best learning environment (or commercial SwiftForth, which is free for personal use).
As a casual programmer in Python I cannot praise enough the REPL idea: the fact I can experiment, build and check quite complicated procedures and just check the syntax when dubious (will IF work this way in this context…)
In fact I have moved TWICE this way: first, learning Python and moving from early stages of C++ and compilation to REPL, and the other time leaving LaTeX for InDesign. Ohhhh, the moment of a sweet freedom, when I just could click and have a widow killed instead of (change a parameter, recompile, check pdf, change it a bit more, recompile, check pdf, curse, find another parameter in a TeXbook, da capo x 20)…
A.
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.
Might not want to let everyone in on that.
C is great, GDB is great and learning one with another is a really clever idea.
I’ve always found well targeted print statements more helpful than debuggers, even for complex software, and not just for the purposes of debugging, but for learning a new language as the article is suggesting.
Indeed, with print statements you can see how the program at particular point behaves, how the over all picture looks and then easily figure out the issue how to fix it, because bugs are rarely on a single line, instead they are often broken logic and with debuggers you will not see the big picture.
I’m using logging and print to “debug” stuff 95% of the time. Yet, sometimes debuggers are useful, especially if you’re dealing with segfault or memory allocation issues which are pretty damn hard to find with print.
Also, valgrind is a very good tool.
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.
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.
Coder from the clouds (*), meet C, C meet coder from the clouds.
Well, I’m all for a little experimentation and whatnot, but seriously, reading a bit about C/C++ (in this especially about pointers and related topics) before trying to poke around in the dark would really, really be the wise thing to do, for multiple reasons. You’d progress faster, understand easier, and wouldn’t have to write such posts for no good reason, sorry.
(*) i.e. coding while flying so high, pointers can’t be seen anymore
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.
Gdb is a good tool for learning low-level representations of programs (not just these written in C). Nothing beats exploring memory/stack/data structure with your own hands. It can also be useful in debugging but at large scale it is less efficient than tracing.
But REPL? No way. Yes, gdb can perform some primitive C operations (arithmetics, dereferencing pointers) but that’s about it. What about calling user-defined functions and defining them? Or, mallocing memory, connecting to the net, opening and parsing files? Even if all this was possible, C is simply too low level to make it a convenient way of writing programs.
That’s why he uses the term pseudo-REPL.
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.
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”.
That’s why he didn’t call it an REPL. He called it a PSEUDO REPL. Are you retarded?
PSEUDO.
PSEUDO.
PSEUDO.
Call it what you want, it’s still not REPL.
(okay, just trolling)
What was wrong with c-repl or ccons? Never saw the author evaluating any of the third party REPLs for C, or even stating that they exist.
Full disclosure: I have never tried any of them so they might suck balls, but it would be nice to at least have them mentioned.
The GDB interface looses points with me, it lacks alot of the visualizations I desire from a debugger. I’ve tried GDB front ends like DDD and codeblocks on linux, but there are too many rough edges. They still exposes a lot of things I don’t like about GDB. Though I couldn’t say why, GDB front ends tend to run very slowly for me.
My all time favourite debugger has to be the excellent borland turbo pascal/c debugger for dos. Yes that was text mode. It supported: mixed source/assembly stepping, C expression evaluation, Multi-file source tracking, Structure visualization, Conditional breakpoints. It even supported remote debugging, which I made terrific use of when I was writing my OS. It became obsolete with DOS a decade and a half-ago, but I still yearn for something as elegant as it was to run on linux. It’s a shame MS put them out of business with such inferior tool-chains.