Usually calling C code from C++ is not too much of a problem. You do
compile the C modules separately, and then link the various bits. C++
provides:
extern "C" {...}
for just that purpose.
http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
yeah...
going partly OT here:
in my own projects, extern "C" is essentially necessary to interface any
C++ code to my scripting VM technology as, sadly, it has currently no
real ability to understand C++ code or interface with the C++ ABIs.
I "could" eventually try to address this, but sadly this is not really
likely to be a small or easy task (doing semi-transparent interfacing
between C++ and a language using dynamic+soft typing, is likely to get a
bit hairy).
previously, I had taken a more strict "C only" policy for these reasons
in many areas in the codebase, although later I came to better
understand how a lot of this can be made to work.
however, apart from in certain cases, such as in largish self-contained
regions of logic code, which do something other than sit around
exporting piles of library functions, C++ offers no particular advantage
(it would be sort of a waste to use C++ just to have nearly everything
marked as extern "C").
in my case, this renders C++ as a minor-use language in my case (the
bulk of code in my case is plain C).
funny thing is, much like C++, my scripting HLL defines a vaguely
similar mechanism:
native package C { ... }
which serves a similar role (it is a hint for tools to export any
contained functions/... to C, generally spitting out headers and wrapped
versions of the function calls as C code).
note: emitting wrapped calls is needed as C is otherwise incapable of
late-binding or linking against thin air, so one needs wrappers to
redirect the call into the HLL VM. well, planned, at least. the current
mechanism is built on DLL-exported function pointers, called "proxies",
but this is nasty and poses portability worries. sadly, there is not an
"ideal" way to handle cross-language interfacing (one either has to call
via a function pointer, or make an API call, or something...).
so, it is possible to interface between my language and C++ by having
each pretend that the other is C, and operating at the level of the C ABI.
also possible (partially tested before as an experiment) was to in turn
compile some of the code as C++/CLI, which in-turn allowed calling into
the script VM from C# (C# -> C++/CLI -> C -> BS).
a lot of this is partly because of a personal belief that cross-language
interfacing should (ideally) not involve manually writing piles of ugly
glue code (and HLL VM's should not be isolated mono-language islands).
but, on to the topic:
if extern "C" can be made to work, this is likely a preferable strategy
to rewriting all of the code in plain C.
.