In the section on memory management, I was surprised that there was no mention of providing a malloc/free method (or some other memory allocator) to the library to explicitly use. This is especially handy if you're working with limited memory environments prone to fragmentation, where you might want the library to call your custom allocator which is managing small memory pools.
What's a well-regarded C library of medium complexity (something that isn't going to be the entire kernel of an application) that does that? I can't think of an example off the top of my head.
If possible provide non-callback versions of your functions. It's very useful when trying to use the "C" api from a different language, and callbacks being very hard to put in. (C -> otherlang -> (callbacks again) C).
Or, instead of making C a more pleasant language for developing applications and middleware libraries, you could use a programming language better suited to those tasks. Call out to C only when necessary and at the lowest layers. Don't layer C on C. Even C++ is an order of magnitude more pleasant when it comes to serious application development and building large, layered systems.
Would I write a C library that gives callers a transitive dependency on D-Bus, or contains an epoll event loop? No.
When I write C, it's typically either (1) small djb-style applications that make a bunch of system calls and don't need any data structures beyond C arrays, or (2) libraries of essentially functional code that do performance critical computations. I love C, and it has its place: near the bare metal.
i'd actually much prefer a lot of handy libraries (e.g., boto comes to mind) be written in C, and exported to higher level languages.
that way, each language wouldn't have to duplicate every other language's effort. the end result would probably be more unified APIs and more complete libraries.
I didn't even notice that there were a large number of links in the post. I think the majority of them would be useful for someone unfamiliar with some of the topics described, though. The great thing about hypertext is that links are optional, so an abundance, as long as the linked content is of quality, hurts no one.
[+] [-] shaggyfrog|14 years ago|reply
[+] [-] tptacek|14 years ago|reply
[+] [-] asher|14 years ago|reply
[+] [-] malkia|14 years ago|reply
[+] [-] sigil|14 years ago|reply
Would I write a C library that gives callers a transitive dependency on D-Bus, or contains an epoll event loop? No.
When I write C, it's typically either (1) small djb-style applications that make a bunch of system calls and don't need any data structures beyond C arrays, or (2) libraries of essentially functional code that do performance critical computations. I love C, and it has its place: near the bare metal.
[+] [-] burgerbrain|14 years ago|reply
This is just language trolling in thin disguise.
[+] [-] unshift|14 years ago|reply
that way, each language wouldn't have to duplicate every other language's effort. the end result would probably be more unified APIs and more complete libraries.
[+] [-] smcl|14 years ago|reply
[+] [-] gue5t|14 years ago|reply
[+] [-] forgotusername|14 years ago|reply
There's a bunch more recent articles on his blog covering similar topics