[PD] C++ for reusable dsp lib - or better use C?

[Mathieu Bouchard]

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