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

katja katjavetter at gmail.com
Wed Feb 22 15:30:50 CET 2012


These questions, distilled from the discussion, reflect my dilemma:

'Why use C for object oriented programming if you have C++?'

'Why use object oriented programming at all, if you have C?'


Pd classes can be done in C very well, if procedures are not too
complicated and not meant to be used in other contexts. But an
independent reusable library will need equivalents for constructor /
destructor, access methods, private procedures and private data. When
writing C, one has to invent an approach for that, or copy an existing
style. It's in any case more tedious than using C++.

For a reusable audio analysis lib I would straightforwardly use C++,
where it not for the considerations mentioned by Mathieu, Hans and
Marvin. The intricate runtime support required for C++ leads to
specific incompatibilities which don't exist for C.

The audio analysis lib I'm planning to do will be intended for static
linking. A collection of useful routines which may be used
individually, or combined as integrated analysis-engine, in the
context of a framework like Pd, MaxMsp, SuperCollider. None of it's
API symbols need be exported globally. The problem is sort of
transferred to the application programmer. Pd's API m_pd.h is well
prepared for compilation with g++. You only need not forget to export
the setup symbol as "EXTERN C".

I use to link GNU C++ standard libs statically, just in case my class
is used with a Pd which doesn't have them. This adds more than 100 KB
to the executable size, not so nice detail. Then I'm not even talking
about version incompatibilities, of which I was unaware till Mathieu
mentioned it.

A C lib would not impose all these concerns on an application
programmer. I'm inclined to look at C once more.
(flip-flop-flip-flop...)

Katja



More information about the Pd-list mailing list