[PD] C++ for reusable dsp lib - or better use C?
matju at artengine.ca
Tue Feb 21 16:59:59 CET 2012
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
More information about the Pd-list