- Leave out the _real_ object orientation and write the main external code
in C++, but not using a lot of the C++ features. I think, that's what
Yves [snip]
extern "C" void stksitar_tilde_setup(void) So obviously this function needs special treatment, whereas the others work without the extern declaration. Why does 2) work? Can I just code right away in C++, and then just declare the _setup function as 'extern "C"' and all is well? I don't think so, but where is this the right, or the convenient way to go?
The basic problem is with what is called "name mangling" - the compiler does stuff to the name symbols to make the job of the linker straight forward. In C++ this mangling is quite bad 'cos it puts the class name in as well. In C its fairly inocuous. Basically you need to declare the functions that PD is going to call outside of classes with extern "C" - you can use all of C++'s features without any problems (it all compiles down to machine code anyway) and you can call classes without any problem from within these funcitons.
Interestingly the PD external code are very object oriented - class methods in C++ have a hidden pointer to the class as the first argument - in PD this is explicit. It would be a very small leap to convert PD externs into C++ classes - all most of them would need would be the first arg removing and "x->" changing to "this.". Pointers to function are messier in C++ but you can get round it with macros. I don't know if Miller has considered it but converting PD to C++ might make writing externals a bit more pleasent.
As an point of interest most of C++ can be implmented as a pre-process to C.
My girlfriend is being induced tomorrow so I will dig the source code out at the start of next week I guess all things being well..
mark