Le 2012-02-21 à 16:36:00, katja a écrit :
Quite some dsp libs are written in C, even today.
It's inertia. It's a bit like how FORTRAN and COBOL and BASIC are still used today, except that C has had such a tremendous influence, that most of its potential replacements also look a lot like C.
Is there good reason to refrain from C++'s conveniences for writing classes, and use C instead?
The big problem I'm aware of, is that GEM binaries for Windows ship as MSVC binaries instead of GCC4 binaries, and that prevents any GCC4 binaries from interacting with its C++ functions.
ABI compatibility is still an issue with C++. GCC has had at least three different ABI versions, but they haven't changed it in years. I'm not counting the libstdc++ version conflicts in shared libraries that contain a static libstdc++, which causes a crash at startup (maybe you can avoid it by disabling try/catch, but at this point, I'm using that feature).
If I could figure out how to call MSVC C++ functions from GCC4 modules, I'd probably find out that using throw/catch will crash or do something weird that doesn't work. Both ABI standards are variants of the same CDECL ABI (that is, non-PASCAL), but they differ in how they encode class names, arg types, namespaces, within symbols... and how try/catch works.
But when going through Pd's API, everything talking to Pd will be able to talk to anything else talking to Pd. It's just an issue when you have to avoid Pd in order to get access to external-specific data types such as GEM's pixes, PDP's packets and GF's grids, and this usually involves calling functions. In the case of PDP, it's all fine because it's all in C, but both GEM and GF are written in C++ and have a C++ API.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC