[Development] Update on C bindings idea

[Giuseppe D'Angelo]

On 13/01/2023 02:38, samuel ammonius wrote:
> Hello,
> 
> About a year ago, I emailed here asking if C bindings could be added to 
> Qt's official repo, and since then I've written a pretty large python 
> script that generates the wrappers by reading Qt's header files. I 
> originally thought that "inline extern" function declarations would make 
> the compiler copy the binary code of the function into the caller 
> program, but I just found out that the compiler ignores "inline" in this 
> case. 

That's not what `inline` is for. Did you try doing a static build, and 
enable a sufficiently aggressive LTO?


I don't think that makes the idea of C wrappers useless, but
> there's another method of binding to C that could dodge the performance 
> issue, and maybe even make Qt run faster on C++ (or at least compile 
> faster). It does interfere with Qt's existing codebase way more than the 
> wrapper method though, so I understand if it wouldn't be accepted.
> 
> The idea is to give Qt functions C-compatible names, and then wrap them 
> with "inline" functions inside a class. This code outlines the idea:
> 
>     // qpushbutton.h
> 
> 
>     struct QPushButton_struct {
> 
>     bool flat;
> 
>     }
> 
> 
>     void QPushButton_setFlat(QPushButton *btn, bool flat);
> 
> 
>     bool QPushButton_flat(QPushButton *btn);
> 
> 
>     #ifdef __cplusplus
> 
>     class QPushButton : private QPushButton_struct {
> 
>     public:
> 
>     Q_ALWAYS_INLINE auto setFlat(bool flat){ QPushButton_setFlat(this,
>     flat); }
> 
>     Q_ALWAYS_INLINE auto flat(){ QPushButton_flat(this); }
> 
>     };
> 
>     #else
> 
>     typedef QPushButton_struct QPushButton;
> 
>     #endif
> 
> Making inline C++ wrappers for C is possible since C++ can read 
> "QPushButton_setFlat", but C can't read "QPushButton::setFlat". This 
> change isn't as drastic as it may seem at first, since all code inside 
> the functions can still use the C++ function names without any 
> difference in behavior or performance. The only change will be in the 
> names of function declarations and definitions, and in how classes are 
> formed. Qt could still be compiled if this is done to certain classes 
> but not others, so the transition wouldn't have to be instant.

I'm not sure what you're proposing here. That all of Qt becomes C code, 
with a C++ wrappers forwarding everything to the C code? That's never 
going to fly.

Besides, what use case do you have for such an effort? If you need a GUI 
for a C program, and you want to use Qt, can't you isolate the "UI 
layer" in your code and use C++ only in that layer, keeping the rest of 
the code in pure C? C++ can interoperate with C out of the box.

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230113/28cba8c1/attachment.bin>