I've seen people try to to create bindings to a C++ library and it
usually involves writing a middle C layer between the
other apps and the C++ library. No point in doing that if we can just
write it in C in the first place.
Hrm. I'm with Olaf on this one. I've had fantastic success with
minimalistic C++ APIs, very clean C exports, and then using FFI (i.e.
ctypes in Python, Inline:: in Perl) in dynamic languages for binding.
And I've even got an example online:
http://blogs.onresolve.com/?p=48
Scroll down a bit and you'll hit a section called 'Interfacing to C
libraries (.dll/.so) using ctypes and decorators'. Using that approach,
I had a product.dll of<25k (forgot the exact size), and I could call
into it from Python, Perl and NSIS, without any reliance on SWIG or
having to write CPython/Perl bridge code in C.
I'm perplexed why anyone would want to forgo the advantages of C++ for
C; I can make my C++ DLLs just as small as C ones. And, like, what if I
want a linked list, or a hash, or a set, are we planning on writing all
of those from scratch? Even string handling alone seems like a huge win.
...
Tried to resist getting involved in this one for as long as I could ;-)
