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 ;-)
Had a quick chat with Elizabeth and we saw eye to eye on a clean C API
(sorta' following the conventions in that blog post) and striving for
dynamic bindings via FFI/ctypes/Win32::API etc, rather than SWIG. So, I
rest my case, I shan't mention the engine and C++ ever again ;-)
Trent.
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : coapp-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
