No language ever came into being more in need of a library than C. The trembling, naked child that opened its eyes on the world it would soon conquer was armed with a mere nosegay of functions consisting of minimal string, memory, math, file I/O, and OS-interface functions. As a programmer it was possible (in fact, routine) to know all the library functions by heart when banging out C code. Only OS calls required consultation with manuals, and even most of those eventually found their ways into developers' muscle memory.

However, development was characterized by frequently writing (and rewriting) code to handle collections, memory management, date computations, networking, and so on. Many a programmer will recollect the innumerable implementations of linked lists that had to be written because, in fact, no standard library for them existed.

In light of such need, in addition to the great popularity of C, you would think that a wide variety of solutions would have flourished. But in fact, the number of general-purpose libraries for C is comparatively small. And those that make the cut are not exactly hot springs of activity.

For pure C, there are essentially three non-GUI choices: the Apache Portable Runtime (APR), glib, and the Mozilla Netscape Portable Runtime (NSPR).

All three libraries were offshoots of larger projects — of the Apache Web Server, GNOME, and Mozilla's many projects — so they're demonstrably portable and battle tested, although as we'll see, the support for users with questions about features or defects varies widely.

All three provide sophisticated memory management, network I/O functions, and a wide variety of collections. After that, each library takes its own path. The NSPR has decent online documentation. It appears to be developed and supported by a single individual who works for Red Hat. The mailing list is overgrown with spam, in which are buried news of updates. Questions by users seem to go unanswered. On the evidence, I'd say that Red Hat supports it to the extent it needs it, and there is no longer any community around the product.

The APR is a larger library containing an additional layer of higher-level functions that do things such as handle XML, database access, cryptography, and the like. And the APR community, while small, is active. The mailing list is maintained. However, there is no usable documentation for the library. The little there is consists of out-of-date Doxygen docs that only explain syntax. The design of the APR, the API to use for a given problem, and so on, is all data held in the heads of the cabal that updates it. This is obviously a seriously gating factor, made worse by the unusual memory allocation design APR uses. It's neither intuitive nor obvious, but it must be mastered to use the APR effectively. So, except for the needs of the Web server and other C projects (such as Subversion), which are developed from people originally exposed to the APR, it's a very difficult library to use.

In contrast, glib has acceptable documentation (far better than APR and somewhat better than NSPR). This would make it a natural choice, especially because it has the entire GNOME series of libraries and utilities in its ecosystem. However, glib is very much a child of UNIX/Linux parentage. To run it on Windows, you have to include the MinGW package. And while there is a minimal set of Win32-specific APIs, these are few in number and of limited use. The documentation is conspicuous in ignoring Windows and matters related to the platform. Given that GNOME is a Linux-oriented package, this may seem natural, but for many potential adoptees, this aspect will be offputting. If this limitation is not a problem, then glib is likely the best option here.

The upshot is that while these three C libraries fill in the missing functionality of the language, none of them is a compelling or natural choice. Each has limitations or obstacles that preclude enthusiastic adoption. In this way, C and C++ are vastly different languages. C++, for all the complaints about its complexity, does provide the STL and will soon include many Boost libraries in its own standard library — all of which are well documented, well supported, and widely used.

Coming Soon
Later this month, we'll be inaugurating a series of articles by Andrew Koenig and Barbara Moo on the new features in the C++0x standard.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy