"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."
Post a Comment
Member since:
2008-08-28
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).
Member since:
2012-08-28
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.
Member since:2008-10-09
Member since:2008-08-27
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.
Member since:2005-08-18
Member since:
2008-10-09
Member since:
2007-02-18
Member since:2008-10-09
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.
Member since:2010-06-24
Member since:2007-02-18
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.
Member since:2007-09-23
Member since:
2005-07-06
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
Member since:2007-09-23
Member since:
2009-06-30
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.
Member since:2007-02-18
Member since:2009-06-30
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.
Member since:2007-02-18
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.
Member since:2009-06-30
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".
Member since:2007-02-18
Member since:2011-05-12
Member since:
2007-09-23
Member since:
2011-01-28
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.