Linked by Thom Holwerda on Tue 28th Aug 2012 19:20 UTC, submitted by MOS6510
General Development "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."
Order by: Score:
Zbigniew
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).

Reply Score: 3

REPL - a key to success
by 108adams on Tue 28th Aug 2012 20:14 UTC
108adams
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.

Reply Score: 2

REPL - a key to success
by wigry on Tue 28th Aug 2012 20:21 UTC in reply to "REPL - a key to success"
wigry Member since:
2008-10-09

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!

Reply Score: 5

REPL - a key to success
by dnebdal on Wed 29th Aug 2012 09:20 UTC in reply to "REPL - a key to success"
dnebdal Member since:
2008-08-27

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. ;)

Reply Score: 2

REPL - a key to success
by Soulbender on Tue 28th Aug 2012 23:32 UTC in reply to "REPL - a key to success"
Soulbender Member since:
2005-08-18

Ohhhh, the moment of a sweet freedom, when I just could click and have a widow killed


Might not want to let everyone in on that.

Reply Score: 3

nice angle
by wigry on Tue 28th Aug 2012 21:01 UTC
wigry
Member since:
2008-10-09

C is great, GDB is great and learning one with another is a really clever idea.

Reply Score: 2

Debuggers
by kwan_e on Wed 29th Aug 2012 02:21 UTC
kwan_e
Member since:
2007-02-18

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.

Reply Score: 2

RE: Debuggers
by wigry on Wed 29th Aug 2012 07:42 UTC in reply to "Debuggers"
wigry 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.

Reply Score: 2

RE: Debuggers
by bouhko on Wed 29th Aug 2012 08:24 UTC in reply to "Debuggers"
bouhko Member since:
2010-06-24

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.

Reply Score: 2

RE[2]: Debuggers
by kwan_e on Wed 29th Aug 2012 08:45 UTC in reply to "RE: Debuggers"
kwan_e Member since:
2007-02-18

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.

Reply Score: 2

RE: Debuggers
by ephracis on Wed 29th Aug 2012 20:19 UTC in reply to "Debuggers"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

C
by l3v1 on Wed 29th Aug 2012 06:53 UTC
l3v1
Member since:
2005-07-06

We've seen that in some situations a acts like an array and in others it acts like a pointer to its first element. What's going on?


Coder from the clouds (*), meet C, C meet coder from the clouds.

is there a difference between the pointer that a decays to and &a ... decayed value of a is a pointer to a's first element ... distinction between a's decayed value and &a


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

Reply Score: 3

RE: C
by ephracis on Wed 29th Aug 2012 20:21 UTC in reply to "C"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

Not REPL
by ndrw on Wed 29th Aug 2012 07:56 UTC
ndrw
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.

Reply Score: 2

RE: Not REPL
by kwan_e on Wed 29th Aug 2012 08:38 UTC in reply to "Not REPL"
kwan_e Member since:
2007-02-18

That's why he uses the term pseudo-REPL.

Reply Score: 3

RE[2]: Not REPL
by ndrw on Wed 29th Aug 2012 10:21 UTC in reply to "RE: Not REPL"
ndrw 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.

Reply Score: 1

RE[3]: Not REPL
by kwan_e on Wed 29th Aug 2012 11:29 UTC in reply to "RE[2]: Not REPL"
kwan_e Member since:
2007-02-18

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.

Reply Score: 3

RE[4]: Not REPL
by ndrw on Wed 29th Aug 2012 11:53 UTC in reply to "RE[3]: Not REPL"
ndrw 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".

Reply Score: 1

RE[5]: Not REPL
by kwan_e on Wed 29th Aug 2012 11:57 UTC in reply to "RE[4]: Not REPL"
kwan_e Member since:
2007-02-18

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.

Reply Score: 3

RE[6]: Not REPL
by MOS6510 on Wed 29th Aug 2012 12:04 UTC in reply to "RE[5]: Not REPL"
MOS6510 Member since:
2011-05-12

Call it what you want, it's still not REPL.

(okay, just trolling)

Reply Score: 2

No mention of third party REPLs for C
by ephracis on Wed 29th Aug 2012 20:28 UTC
ephracis
Member since:
2007-09-23

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.

Reply Score: 2

GDB
by Alfman on Thu 30th Aug 2012 03:41 UTC
Alfman
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.

Reply Score: 2