4 ms·

> C++ has standardized ABIs but you just don't see people dynamically loading a C++ shared object, obtaining a pointer to a C++ object and calling its member fu

> C++ has standardized ABIs but you just don't see people dynamically loading a C++ shared object, obtaining a pointer to a C++ object and calling its member functions. They always do it through the C ABI if they do it at all. That does not match my experience at all. From the top of my head, Qt (QtPlugin) does C++ ABI plugins, and they do that almost transparently in a myriad of platforms. > I just get this incredibly hopeless feeling whenever I try to contemplate how I'd handle a C++ exception from Python code. At one point I could even catch C++ exceptions from Java, and viceversa (see gcj).

matheusmoreira 4y ago
> From the top of my head, Qt (QtPlugin) does C++ ABI plugins This? https://wiki.qt.io/Plugins https://wiki.qt.io/Plugins > provides a bunch of macros that helps us create the C-function that generates the plugin object Looks like it uses the C ABI. > At one point I could even catch C++ exceptions from Java, and viceversa (see gcj). I'm interested in the details of that. Perhaps the GCJ compiler generated some sort of bridge between the languages?
- flohofwoe 4y ago
  As far as I'm aware, the Qt DLLs themselves just expose C++ class APIs directly without going through a C API wrapper, that's why there's a separate Qt SDK for every MSVC version (and all hell breaks loose if you accidentally mismatch DLLs).
  - matheusmoreira 4y ago
    Yes, Qt itself is a C++ library. AshamedCaptain was talking about the plugin interface though which is just dynamically loadable modules for Qt applications. I looked it up and those things export C functions that return the C++ objects and meta-object system data.
    - AshamedCaptain 4y ago
      They export _C++_ functions. You can't return a C++ object from a C function (unless you start making assumptions from the C++ ABI).
- AshamedCaptain 4y ago
  > looks like it uses the C ABI. Only in the sense that C++ itself "uses the C ABI". This is still C++ ABI; most if not all of the plugin types inherit from C++ classes and there are no code wrappers generated whatsoever (except the usual moc slot unmarshallers if you want to be really picky, but these are not going to be ones you'll be calling). These macros are there for discovery and enumeration/reflection. After you have constructed the root plugin object, you are calling it through the C++ ABI, vtables included (since actually you call it through the base class). > I'm interested in the details of that. Perhaps the GCJ compiler generated some sort of bridge between the languages? The C++ exception/"personality" ABI is kind of designed for this, which is one of the reasons it may appear complex and/or slow. Just search for gcj exceptions for examples.
  - matheusmoreira 4y ago
    > Only in the sense that C++ itself "uses the C ABI" Not at all. Qt literally uses the C ABI as a protocol for plugins. I have no doubt they chose it because it's the only inferface simple and stable enough for the task. It is relatively simple and stable precisely because there are zero C++ features involved. I thought that alone was damning enough so I didn't elaborate further. What you said is absolutely true: the objects returned by those C functions are accessed by the real C++ ABI with vtables and everything. That's a massive problem and they shouldn't have been designed this way. Look at the mess this causes: https://forum.qt.io/topic/119767/qt-plugin-fixing-c-abi-problems-with-external-c https://forum.qt.io/topic/119767/qt-plugin-fixing-c-abi-prob... > 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. The solution is, of course, to get rid of all this C++ business and restrict yourself to the C ABI. This is apparently the fate of every ABI that isn't C. When even that is annoying enough to deal with, nobody is ever going to want to deal with anything more complex.
flohofwoe 4y ago
> but you just don't see people dynamically loading a C++ shared object ...that's exactly how Autodesk Maya plugin DLLs work, and it's a PITA, because DLLs need to be recompiled with a specific MSVC version for each new Maya version. Qt DLLs on Windows are also separate for each MSVC version.
- matheusmoreira 4y ago
  Yeah... I suppose that's why we don't see people doing it anymore. That's what I hope at least.
  - pjmlp 4y ago
    I suggest learning how WinUI works.

matheusmoreira 4y ago

> From the top of my head, Qt (QtPlugin) does C++ ABI plugins This? https://wiki.qt.io/Plugins https://wiki.qt.io/Plugins > provides a bunch of macros that helps us create the C-function that generates the plugin object Looks like it uses the C ABI. > At one point I could even catch C++ exceptions from Java, and viceversa (see gcj). I'm interested in the details of that. Perhaps the GCJ compiler generated some sort of bridge between the languages?

flohofwoe 4y ago
As far as I'm aware, the Qt DLLs themselves just expose C++ class APIs directly without going through a C API wrapper, that's why there's a separate Qt SDK for every MSVC version (and all hell breaks loose if you accidentally mismatch DLLs).
- matheusmoreira 4y ago
  Yes, Qt itself is a C++ library. AshamedCaptain was talking about the plugin interface though which is just dynamically loadable modules for Qt applications. I looked it up and those things export C functions that return the C++ objects and meta-object system data.
  - AshamedCaptain 4y ago
    They export _C++_ functions. You can't return a C++ object from a C function (unless you start making assumptions from the C++ ABI).
AshamedCaptain 4y ago
> looks like it uses the C ABI. Only in the sense that C++ itself "uses the C ABI". This is still C++ ABI; most if not all of the plugin types inherit from C++ classes and there are no code wrappers generated whatsoever (except the usual moc slot unmarshallers if you want to be really picky, but these are not going to be ones you'll be calling). These macros are there for discovery and enumeration/reflection. After you have constructed the root plugin object, you are calling it through the C++ ABI, vtables included (since actually you call it through the base class). > I'm interested in the details of that. Perhaps the GCJ compiler generated some sort of bridge between the languages? The C++ exception/"personality" ABI is kind of designed for this, which is one of the reasons it may appear complex and/or slow. Just search for gcj exceptions for examples.
- matheusmoreira 4y ago
  > Only in the sense that C++ itself "uses the C ABI" Not at all. Qt literally uses the C ABI as a protocol for plugins. I have no doubt they chose it because it's the only inferface simple and stable enough for the task. It is relatively simple and stable precisely because there are zero C++ features involved. I thought that alone was damning enough so I didn't elaborate further. What you said is absolutely true: the objects returned by those C functions are accessed by the real C++ ABI with vtables and everything. That's a massive problem and they shouldn't have been designed this way. Look at the mess this causes: https://forum.qt.io/topic/119767/qt-plugin-fixing-c-abi-problems-with-external-c https://forum.qt.io/topic/119767/qt-plugin-fixing-c-abi-prob... > 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. The solution is, of course, to get rid of all this C++ business and restrict yourself to the C ABI. This is apparently the fate of every ABI that isn't C. When even that is annoying enough to deal with, nobody is ever going to want to deal with anything more complex.

flohofwoe 4y ago

> but you just don't see people dynamically loading a C++ shared object ...that's exactly how Autodesk Maya plugin DLLs work, and it's a PITA, because DLLs need to be recompiled with a specific MSVC version for each new Maya version. Qt DLLs on Windows are also separate for each MSVC version.

matheusmoreira 4y ago
Yeah... I suppose that's why we don't see people doing it anymore. That's what I hope at least.
- pjmlp 4y ago
  I suggest learning how WinUI works.