Comments on: Problems with C and C++ Separate Compilation

By: csgordon

csgordon — Fri, 21 Nov 2008 07:56:52 +0000

You’re right, that sort of approach to APIs can certainly handle it, but that’s not the solution you want. It essentially means that every library or component, every *object file* is responsible for managing its own memory, and for providing a handle-base API for structures whose definitions it owns. Between libraries, that’s reasonable, though it adds a lot of boilerplate engineering overhead. For separate object files within the same component, it seems like overkill.

The prefixing workaround to get de facto namespaces (which are basically syntactic sugar for prefixing; look at the symbol names compilers generate) and the automated tools for tracking dependencies by reading source also work. I’m not trying to say that these things are insurmountable; they absolutely can be managed and mitigated. But these are problems which don’t need to exist, shouldn’t require workarounds and aren’t present in some other languages.

By: Dave Pacheco

Dave Pacheco — Thu, 20 Nov 2008 06:27:40 +0000

N makes a good point: many of these problems can be solved through careful API design. Accessor routines for user-visible data and/or stable structures allocated and freed with API calls make structure incompatibility less of an issue. You can also version API’s in such a way that binary incompatibilities lead to quick init-time failures rather than arbitrary data corruption. OpenSolaris does this all over the place – see fmd_hdl_register, for one:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/fm/fmd/common/fmd_api.c#fmd_hdl_register

C also has namespaces – in the form of identifier prefixes. It’s the same thing, except unenforced and more explicit (the latter of which is a good thing).

Mark, I can’t think of any language that doesn’t allow developers to use relative paths for importing external modules. Such languages necessarily require a “path” of places where those modules might be located. This includes C, Java, Perl, Python, Ruby, …. What’s the alternative?

By: Ben

Ben — Wed, 19 Nov 2008 07:03:09 +0000

The tool ‘makeheaders’ might alleviate some of your problems, though I haven’t used it myself: http://www.hwaci.com/sw/mkhdr/

By: mark

mark — Wed, 19 Nov 2008 06:10:43 +0000

GNU autotools? The ugly and horrible macro language that people try to replace with scons or cmake since quite some time by now?

The problem is the language itself. I think namespaces should be introduced for header files as well. It is silly to require .h files to be put at specific paths rather than have it “register” somewhere (on a traditional system it is “registered” by being put at a specific place on a hdd, but this model is suboptimal imho)

By: N

Wed, 19 Nov 2008 05:07:37 +0000

This is why well designed C and C++ libraries make use of opaque pointers to data structures. It avoids the problem of having to deal with changing data layouts in your client code. As long as you work with API functions to modify opaque data in your client code, you don’t need to worry about changes to the internal layout and structure of the opaque data.

> It’s possible to work around this problem with a build system if you track every header file dependency explicitly.

Try GNU autotools or SCons.