Hello all
I am trying to use a library for some sc plugins that requires c++14. Bumping the version of c++ in my sc plugins’ CmakeLists.txt from 11 to 14 seems to work fine. But since SC is still built using 11, could this be potentially disastrous?
Thanks!
The plugin interface is MOSTLY a C interface. There are a few COM-compliant C++ bits, but these (by nature of being COM) are basically stable across compilers and C++ versions.
The case where you would see problems for different C++ versions across a plugin boundary is in cases where you’re passing standard library objects from different versions of libc++ across the boundary. So, if you have a plugin interface where the host passes an std::string from an older libc++ to a plugin built with a newer, you would definitely have a problem if e.g. the internal storage structure of that string has changed.
Off the top of my head, if you were use objects built from code-identical versions of a library (libc++ or otherwise) but compiled with different C++ versions, I think you would still have a guarantee of everything working correctly - but I’m not TOTALLY sure about this. But, to go back to my first point: the SC plugin API does not do this, and indeed basically no plugin API would do this b/c it’s generally considered very bad practice.
There are a few COM-compliant C++ bits, but these (by nature of being COM) are basically stable across compilers and C++ versions.
Except for SCFFT_Allocator 
SCFFT_Allocator not ABI compatible · Issue #4438 · supercollider/supercollider · GitHub
Adding to @scztt’s comment, not only does the C++ standard not matter, you can also use different C++ compilers. Scsynth and plugins appear to each other as a block-boxes.
Thanks for the answers both of you! I will continue mismatching as if there was no tomorrow! 