C Craft
crypto.stanford.edu
C Craft
1–10 of 60 posts
Re: C Craft
#2C is not simple and brief for all things, though - for example, details of resource management leak across library interfaces, complicating things. Sometimes using C is a reasonable trade-off, sometimes not. Still, it's small and simple, and it's weaknesses are reasonably well known. It's a useful tool, though prototyping and exploratory programming are not its strong suit.
I find I'm happiest working in a language that allows very easy integration with C, but provides garbage collection, some kind of module system, better strings, a REPL, etc. You have more flexibility while prototyping, but can rewrite the parts in C that need it, and all system calls (fork, dup2, etc.) are still accessible. Having a pervasive associative array ("dict" or "table") type in the language helps, too - it's an incredibly versatile data structure.
Lua works particularly well for this (and it's simple and clean, like C), though Python and Lisps/Schemes that compile to C work well too. (I can't vouch for Ruby here, since I already know Python and Lua and haven't bothered with it.)
See also: Andrew Koenig's "C Traps and Pitfalls" (http://www.literateprogramming.com/ctraps.pdf) and the book, which expands on the paper.
Re: C Craft
#3Honstly, OOP isn't that bad. This would be a lot better of a read if he focused on how C is good, not how he hates OOP. OOP is a valid way to solve any problem, though certainly not the only valid way.
Incidentally I wrote an article in defense of OO: http://www.zideck.com/blog/article.php?id=1
Re: C Craft
#4C is not simple and brief for all things, though - for example, details of resource management leak across library interfaces, complicating things. Sometimes using C is a reasonable trade-off, sometimes not. Still, it's small and simple, and it's weaknesses are reasonably well known. It's a useful tool, though prototyping and exploratory programming are not its strong suit. I find I'm happiest working in a language t…
I think that what's particularly hard with C is not the details about pointers, automatic memory management, and so forth, but the fact that C is at the same time so low level and so flexible.
So basically if you want to create a large project in C you have to build a number of intermediate layers (otherwise the code will be a complete mess full of bugs and 10 times bigger than required).
This continue design exercise of creating additional layers is the hard part about C. You have to get very good at understanding when to write a function or not, when to create a layer of abstraction, and when it's worth to generalize or when it is an overkill.
Of course the same thing happens in other languages as well, and even in higher level languages, but usually in C there are more layers of abstractions required compared to a similarly complex project written in an higher level language.
Another difference with higher level languages is that with C the abstraction layers at the "bottom" usually have to deal with low level details that require some practice and knowledge. For instance it's common to implement data structures, some automatic memory management stuff like reference counting and so forth.
This is the reason why I think programmers should learn C and try to write at least a large project with it: it's a good exercise.
Re: C Craft
#5C is not simple and brief for all things, though - for example, details of resource management leak across library interfaces, complicating things. Sometimes using C is a reasonable trade-off, sometimes not. Still, it's small and simple, and it's weaknesses are reasonably well known. It's a useful tool, though prototyping and exploratory programming are not its strong suit. I find I'm happiest working in a language t…
I think that what's particularly hard with C is not the details about pointers, automatic memory management, and so forth, but the fact that C is at the same time so low level and so flexible. So basically if you want to create a large project in C you have to build a number of intermediate layers (otherwise the code will be a complete mess full of bugs and 10 times bigger than required). This continue design exercis…
Indeed. FWIW, _C Interfaces and Implementations_ by David Hanson touches on this (and a great C book besides).
Re: C Craft
#6Honstly, OOP isn't that bad. This would be a lot better of a read if he focused on how C is good, not how he hates OOP. OOP is a valid way to solve any problem, though certainly not the only valid way. Incidentally I wrote an article in defense of OO: http://www.zideck.com/blog/article.php?id=1
This would be a lot better of a read if he focused on how C is good
Then it would be a Twitter post, not a blog post.
Re: C Craft
#7C is for simple low level system libraries. For all other kinds of computation one has scheme.
Re: C Craft
#8This is great. Every developer should be familiar with writing C and how to hook into it from higher-level languages (Ruby, Python, etc). This is a VERY powerful combination. C isn't appropriate for everything these days, but it can kick ass and take names at very specific tasks that need performance or access to OS primitives.
Re: C Craft
#9I think the author of this document would really appreciate a lot of things in Go. Given his wish for := as the assignment operator, CSP semantics and some other things...
Re: C Craft
#10I think it's telling that the very first example to use dynamic allocation has a memory corruption bug.
struct {
int n;
char c[0];
} *foo = malloc(16); /* sizeof(*foo) probably 4, so 12 bytes follow */
foo->n = 16;
for(int i = 0; i n. oops. */
foo->c[i] = 'a' + i;
}