Qt Plugin: Fixing C++ ABI Problems with "external C"

fem_dev

I'm developing a cross-platform Qt GUI C++ application that should run in Windows, Linux and Mac OSX.
This "main application" will be extended by plugins. I'm already developing some plugins, but the main idea is enable any developer to do new plugins in the future.
Today I'm developing this plugins using QtPlugin and QPluginLoader.

I know that C++ don't have Aplication Binary Interface - ABI compatibility between compilers (example: MSVC, MingW, Clang and ICC). Besides that, the C++ ABI compatibility can be broken even using the same compiler with different version (example: MSVC 2003 and MSVC 2019).

Example: If the main C++ application was compiled using MSVC 2003, all plugin developers MUST HAVE and MUST USE the exactly same compiler to build your projects, in this case MSVC 2003. Which is not good.

Looking in the internet I found a way to fix that: Creating a C Wrapper of my C++ Interface Abstract Class.
Example Tutorial here: https://nachtimwald.com/2017/08/18/wrapping-c-objects-in-c/

My questions are:
1- How to write my Interface header in a way to enable future developers use different C/C++ compilers that I used to build the main application.

2- I will give a plugin example project to the future developers. This project is based on CMake. I saw that CMake have a property called WINDOWS_EXPORT_ALL_SYMBOLS (link here). Is this flag enough to export all DLL symbols in the Windows environment?

3- If I implement a C Wrapper of my C++ Interface, should I still use the QPluginLoader to load plugins in the main application? Or should change to QLibrary?

Could you help me?

Thank you,

My systems are:

OS's: Windows 10, Ubuntu 20.04, OSX 10.15 (all x64)
Qt 5.15.1
Compilers: MSVC 2019, GCC 9.3, Clang 10, MingW-GCC 10, ICC 19

Christian Ehrlicher

@fem_dev said in Qt Plugin: Fixing C++ ABI Problems with "external C":

to the interface functions and still uses Qt C++ signals and slots to transfer data between the plugin and the main app?

Since this is c++ - no.

Christian Ehrlicher

The only way I see is to use C-only functions.

fem_dev

@Christian-Ehrlicher thank you,

Could you please give me more details?

When you said "C-only functions":

1- The C Wrapper do the same job? Or there is some differences?
2- How can I send data from plugin to main app, and from main app to plugin? May be a C Wrapper of a Qt signal and slot?
3- In this case, how to load the new dynamic library?

Thank you,

Christian Ehrlicher

@fem_dev said in Qt Plugin: Fixing C++ ABI Problems with "external C":

The C Wrapper do the same job? Or there is some differences?

Did not read it, but I would guess yes

How can I send data from plugin to main app, and from main app to plugin?

Via c-structs, no c++ allowed.

In this case, how to load the new dynamic library?

Via QLibrary

fem_dev

@Christian-Ehrlicher Thank you,

Last doubt: Thinking about the bi-directional plugin/application communication, is possible to write a C++ header interface that uses extern C to the interface functions and still uses Qt C++ signals and slots to transfer data between the plugin and the main app?

Is yes, in this case, is this fix the compiler-independent problem?
Example: The main app compiled using MSVC 2013 and the plugins compiled with MingW 8? Or MSVC 2013 and MSVC 2019? Or Clang and ICC?

Christian Ehrlicher

@fem_dev said in Qt Plugin: Fixing C++ ABI Problems with "external C":

to the interface functions and still uses Qt C++ signals and slots to transfer data between the plugin and the main app?

Since this is c++ - no.