> How, indeed. That's exactly my point. How could anyone possibly do that? You'd need to implement a C++ compiler frontend in your GetProcAddress and dlsym func

> How, indeed. That's exactly my point. How could anyone possibly do that? You'd need to implement a C++ compiler frontend in your GetProcAddress and dlsym functions just to resolve C++ symbols I still don't follow. C++ symbols are C symbols. Can you put an example of how you can get more C++ than Qt is? If you mean mangling, I don't think you need an entire C++ compiler for it. But even standard C++ contains some escape hatches to avoid mangling (one of them being 'extern "C"'). > The only reason this QtPlugin business even works is you're also writing C++ code and can therefore use C++ calling conventions. I don't disagree with that. My point was that dynamically loadable plugins in C++ -- with "vtables and all" -- not only work, but are in fact frequently used. > Even that is a dance because those conventions are different for every compiler and even individual versions of the same compiler. > So your solution is to just make sure everyone is using the same compiler? This is an entirely different problem that affects _all_ languages. On Windows, as I mentioned, there are even multiple C ABIs (incl multiple calling conventions) and standard libraries and everything you can think of. This is done intentionally, so that they can more easily preserve binary compatibility with older versions. Other platforms have made different compatibility decisions. I think people significantly exaggerate how much "pain" the situation causes (and this comes from someone who has distributed commercial multi-platform C++ software for 20+ years). In any case this is a common problem, dynamic plugins or not, C++ or C. And definitely, this is not something so annoying I would trade dynamic linking for. But that's off topic.