> How is one going to export and GetProcAddress a plugin object factory method in C++?
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. This is why they had to use the C ABI for what you call "discovery". The fact is even getting a simple pointer to a C++ object would be pretty much impossible without a C ABI in there.
To say nothing of actually calling the functions returned with C++ calling conventions. The only reason this QtPlugin business even works is you're also writing C++ code and can therefore use C++ calling conventions. Even that is a dance because those conventions are different for every compiler and even individual versions of the same compiler.
> Ensuring one uses the same version of the MSVC compiler is not so different as ensuring the use of the same version of MSVC that was used to build Qt, or even to use the same version of Qt for the base and gui libraries...
So your solution is to just make sure everyone is using the same compiler? Yeah, easier said than done. Even in the free software ecosystem which hates binary interfaces and has the capacity to rebuild the world if necessary, breaking ABIs cause chaos and pain for everyone.
> 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.
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. This is why they had to use the C ABI for what you call "discovery". The fact is even getting a simple pointer to a C++ object would be pretty much impossible without a C ABI in there.
To say nothing of actually calling the functions returned with C++ calling conventions. The only reason this QtPlugin business even works is you're also writing C++ code and can therefore use C++ calling conventions. Even that is a dance because those conventions are different for every compiler and even individual versions of the same compiler.
> Ensuring one uses the same version of the MSVC compiler is not so different as ensuring the use of the same version of MSVC that was used to build Qt, or even to use the same version of Qt for the base and gui libraries...
So your solution is to just make sure everyone is using the same compiler? Yeah, easier said than done. Even in the free software ecosystem which hates binary interfaces and has the capacity to rebuild the world if necessary, breaking ABIs cause chaos and pain for everyone.