edit just bought it.
Quick scan reveals some GNU extensions being used, lots of tripe about pkg-config, autotools, how to write a makefile properly without autoconf (commendable), gdb tutorial (looks resonable), short valgrind mention, unit testing, doxygen, proper assertions (woot!), short bit on VCS with git (looks reasonable), integration with python (looks reasonable), decent discussion on aliasing and copying, some serious standard-breaking things (bad), how not too shoot yourself with macros (good), linking discussion (looks ok), an odd quote from pussy riot, lots of discussion of gotchas, unicode (good!), some stuff to do with glib (yuck), OOP in C (looks ok), more glib stuff (yuck), posix threading (some mines in there), GSL (good), SQLite (good), libxml (yuck - personal preference though), libcurl (good).
So generally a mix of good and bad. Probably worth it though.
There _is_ a lot of GNU in there, but that's because there's a lot of GNU in the C ecosystem. I made an effort to neither overuse or underuse GNU tools, and this is where I wound up. Also, I made a serious effort to label anything that's GNU-specific as such, e.g., the long segment on the GNU/BSD-specific asprintf() (which I was _so_ disappointed to not see adopted in C11).
Everything tests out on clang unless otherwise stated. In fact, there are little things that work better on clang, because it uses c99 out of the box. E.g., as of this writing, you'll need clang to make the example for (C11) _Generic work. If anything breaks standards without my telling you it does, you can file a bug report at O'Reilly's site for the book (or email me), and I'll fix it in later electronic versions.
As for autotools, I had a sort of epiphany somewhere along the course of writing the book: it's not so bad. At the core, if you want to do something relatively simple, like set up a basic shared library, you can do so in just a few lines of Automake. It's filled with hacks and historical cruft, but as a user I...I've grown to actually like it. Also, as above, it's a huge part of the ecosystem and therefore worthy of discussion for that reason alone. If you don't like it, skip the Autotools chapter and stick with make. I won't know.
My sense of the book so far-- though I've only had it for a day or two-- is that it's pretty balanced in terms of avoiding evangelical fervor for any one tool or approach.
We've needed a book like this for a while :)
I look forward to future editions as well.
People love to gripe about autotools, but if you take the time to understand it and get comfortable with what it is and is not, it will get the job done.
There are alternatives like cmake, but they just suck differently. I use autotools to manage cross-platform (Linux/glibc, Linux/uclibc, mingw32, OS X) C library projects and their Python extension module wrappers, with heavy dependencies on system-specific functionality and symbol replacement (e.g., if strlcpy isn't in libc, then link in libbsd if you can find it there, otherwise compile our own copy of strlcpy.c). Autoconf is a wonderful tool for this once one RTFMs and gets over the fact that it's a bunch of helpers for writing a shell script, rather than a fully abstracted programming language of its own.
Or in the words of Lennart Poettering, "every custom config/makefile/build system is worse for everybody than autotools is":
* Calling out from your C program to the scripting language.
* Setting variables in the scripting language from C.
* Creating functions that can be called from the scripting language.
* Making those available by creating a loadable shared lib that the scripting language can utilize.
Stuff like that is not that different across different languages and if you've figured one out, others won't be that hard.
My take: Tcl's C API is pretty cool. I wrote about it some here: http://www.amazon.com/dp/032133633X/?tag=dedasys-20
I'm not really a Lua fan personally (the confusing indice and ordinal notation scares me), but I can see why it makes sense for integration purposes. Clean, simple, to the point.
Could you expand on this perhaps? The book sounded pretty compelling up until I read that.
The book should have the word "GNU" wedged in it.
I'd like to have seen some discussion of llvm/clang as well.
So really these days "gcc" is as much a common dialect of C as it is a particular compiler.
Also it leads to GObject abuse which is harmful to the soul.
Ultimately, the moment you bring glib into a project it stops being C, much like the Win32 API does.
I'd rather pull in libapr and apr-util.
I used to work at MS and grew very comfortable (and appreciative) of the stylistic choices in the NT kernel (distinct from the Win32 style, one key difference is much less Hungarian notation). But I can jump back into more typical-of-*nix styles with ease. Or the more Win32 style if preferred. I think it's important to see the merits and drawbacks of various style decisions in a non-judgmental fashion, and be able to switch back and forth depending on the code base you're working in. It's a mistake to confuse style and convention with "not being real C". Different doesn't mean not real.
Say what you will, but I see the book's apparent inclusion of glib as a plus.
GObject is a bit different matter - there's quite a bit of boilerplate, which makes me think twice before adding one. But at the same time, it's quite nice to use them in libraries like GStreamer.
GLib is certainly not perfect, but I found it more pleasant to use than, say, talloc. Are there any specific advantage is APR? (I've never used it) Does it cover the same functionality?
I haven't checked recently, but the problem with APR was for so many years it had (possibly still has) no documentation other than Doxygen. Also, the memory pool design seemed an enormous complication. Have you used it recently and have either of those factors improved much?
I've built some seriously complicated stuff which builds on Linux, Solaris and FreeBSD in the past with no autoconf magic required.
Autoconf is just a massive Rube Goldberg machine in disguise.
I think there are more papers on build systems than on sort algorithms.
make -f Makefile.osf1
make -f Makefile.sunos4
make -f Makefile.sunos5
Keep It Simple is the #1 rule. Rule #2 is every bad thing you do will do two things bad back to you in the future.
It uses a shell script to do a little bit of config, then bootstraps mk (a Bell Labs successor to make) and builds everything from some very human-readable mkfiles. When you want to build, you just untar the source and run ./INSTALL
Occasionally, though, my needs will be more complicated than what make can handle on its own (lots of compile-time options, for example, or lots of dependency checking), and in those cases I'll use waf. Waf is lovely and hasn't let me down, and it's easy to use for people who are used to the ./configure && make && sudo make install sequence.
Edit: Sorry, not a referral link.
There is no associate tag.
Seriously? There is a world outside of GNU...
Personally, I stick to POSIX make for most of my code -- and handle cross-platform issues by assuming POSIX compliance and telling people to fix their damn OSes if they're not POSIX compliant.
Projects with small teams who have programmers as audiences can reasonably target POSIX and let their users work out their personal issues themselves. If they are using something particularly weird, that is their own damn fault and they should take responsibility for that. If not, chances are they won't have a problem.
Running HP-UX with a GNU Hurd kernel on your toaster? Fix it yourself. Sure, I'm sure autotools could cover that situation, but seriously, just fix it yourself.
That's a damn sight nicer than "but seriously, just fix it yourself."
I don't think it is fair to accuse me of "blaming the user", as though that were horrific and plainly wrong, just because I want nothing to do with that nonsense again.
That is a valid feeling, but it does not excuse arrogant or condescending behavior. It's not the user's fault that you've had these experiences; you just ended up working with a painful tool. Moving on and refusing to work with it again is perfectly fine. Blaming the users for your misery is not.
"I don't think it is fair to accuse me of "blaming the user", as though that were horrific and plainly wrong, just because I want nothing to do with that nonsense again."
I accused you of blaming the user because of comments such as "If they are using something particularly weird, that is their own damn fault"
Separate the problem from the people, because the people you're attacking are not responsible for your pain.
Anyway, I think we have misunderstood each other.
> "I accused you of blaming the user because of comments such as "If they are using something particularly weird, that is their own damn fault""
I agree with you there. I am blaming the user.
Where we differ is that I have, with admittedly strong words, objected to the implication that blaming the user is inherently wrong or bad to do.
There is a certain amount of work I am willing do to for the sake of the user with use-cases dissimilar to my own. If I'm on linux, and inotify seems like the best too for the job, I'll either abstain from using it, or use it but make an attempt to cover other common possibilities. I think it is my responsibility as a developer to think of others to this degree, if I am simultaneously not following standards and not making concessions, then I am not being fair.
Using autotools is way over that helpfulness threshold though. If that much effort is involved then I am sorry, but I expect the user to do some legwork themselves.
Rather damn good advice. And free like beer should be.
C grammar pocket reference. Pure cheating. Actually has the sample code on how to use C.
Messing with C programs makes things easier.
I hate it. Mainly because the layout and design gets to me. But I can't deny that it has good info.
The next book to read after your intro to C. Actually explains how to write C programs after you know the grammar.
Says object oriented C. But actually it is about using scoping in C to organize your code.
Just about every way you can debug your C program.
Starting Linux programming. Shows how to use system calls. And make a simple web server.
100 Examples of C programs. Brute force yourself into using learning C.
How to use various C libraries like BLAS and Cairo in C.
I know what you are saying, most of these are in Japanese. But the code is not. And rather easy to look at the code and see what they are doing. Anyhow, live dangerous I say. Not many books in English explain this stuff it seems. However, if anyone has nice C related info in any language, I would be appreciative.
This book reminded me of an online C tutorial that proceeded to teach C in a functional style. I don't remember if they explicitly stated it was FP when presenting the material.
The style was really clean. The author avoided assignment as much as possible. All variables were initialized as if they were 'let' statements. Variables were
I just can't find the link anywhere.
Does anybody know that web page that I'm referring to?
I was handed a few lecture notes by my former professor who interned there in the 90s or so.
edit: To clarify, I looked, but couldn't find the notes right now either. Not sure if I still have them.
"The Function Pointer Tutorials":
"The C Language is Purely Functional" - a satirical, but also, thoughtful post that I don't think has been submitted to HN before (or the search system is rubbish):
If this isn't a great resource for embedded C, can anyone recommend a different book?
These days I primarily program web services and iPhone apps in Ruby, occasionally using Java for performance issues. Is there any good reason for me to further my C knowledge?
There's also Alexandrescus "Modern C++" book, but even that is now a decade old. We'll have to see what turns up in the wake of the recent standard, so far it's mostly introductions to new features and some updated references, useful for someone getting reacquainted with modern features, but no K&R of C++11 yet.
I had tried to learn from Stroustrup before C++11 and didn't get as far.
Also the Kindle edition is really well done.
The biggest flaw of this book is that's huge.
It's a hefty tome but that's not necessarily bad if you want to (re-)learn the language and the tricks in a proper way. Easily in my personal Top 5 books for C (The others are in no particular order: "Pointers on C", "Expert C Programming: Deep C Secrets", "The Standard C Library", "C Interfaces and Implementations".)