| 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." |
|
| And now for something completely different... |
| By Zbigniew on 2012-08-28 19:50:44 |
|
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). |
 - Score: 3 |
| REPL - a key to success |
| By 108adams on 2012-08-28 20:14:21 |
|
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. |
| - Score: 2 |
| REPL - a key to success |
| By wigry on 2012-08-28 20:21:26 |
| 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! |
| - Score: 5 |
| nice angle |
| By wigry on 2012-08-28 21:01:59 |
| C is great, GDB is great and learning one with another is a really clever idea. |
| - Score: 2 |
| REPL - a key to success |
| By Soulbender on 2012-08-28 23:32:54 |
|
> 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. |
| - Score: 3 |
| Debuggers |
| By kwan_e on 2012-08-29 02:21:09 |
| 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. |
| - Score: 2 |
| C |
| By l3v1 on 2012-08-29 06:53:16 |
|
> 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 |
| - Score: 3 |
| RE: Debuggers |
| By wigry on 2012-08-29 07:42:46 |
| 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. |
| - Score: 2 |
| Not REPL |
| By ndrw on 2012-08-29 07:56:59 |
|
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. |
| - Score: 2 |
| RE: Debuggers |
| By bouhko on 2012-08-29 08:24:15 |
|
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. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |