On Mar 2, 2012, at 4:32 AM, katja wrote:
On Wed, Feb 29, 2012 at 9:17 PM, Thomas Grill gr@grrrr.org wrote:
Hi Katja, maybe i'm chiming in too late, but i would definitely use C++ programming for whatever i do in the C-world. It's no problem to make the public API (exported functions) C-style then to avoid various hassles. If your library is just a wrapper it might not be worth to live in both worlds, but if it's a substantial amount of code, i would go for C++ with a C interface. gr~~~
Thanks for your recommendation, Thomas. Mathieu and IOhannes did similar suggestions.
Can anyone point me to an example of a C++ lib with C API, in the field of dsp? Not sure if I can think of the best way how to do it.
As I see it now, a C++ class could be instantiated and accessed from C like so:
- define an extern "C" wrapper which calls a class constructor and
returns the pointer to the instantiated object.
- define extern "C" accessor wrappers which take the object pointer as
their first argument, like how you would access data in C structs.
- via the object pointer, the extern "C" accessor wrappers can call
class member functions to access the class private data in C++ style.
How about function call overhead? For constructor and destructor no problem of course, but accessor wrappers will be called often, in fact it doubles the number of function calls for external access.
The C++ ABI compatibility problems are not the only thing that make C++ hard to deploy. On limited platforms like Android, they include limited C++ support, like no exceptions and other stuff. Its still possible to write portable C++, if you track all of these various issues across the platforms you want to support.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom