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