Re: [Development] Update on C bindings idea

Sorry, I just realized this idea breaks binary compatibility. Just ignore it. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

[Development] Update on C bindings idea

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 compi

Re: [Development] [EXTERNAL EMAIL] Could support for C be added to Qt?

> Even though that code has #ifdef __cplusplus, the code doesn't compile as C. > This is C++. Yeah SWIG's output files are in C++. I thought you meant that the C++ functions generated by SWIG should be wrapped rather than wrapping Qt's code directly. This explains a lot. Sorry I forgot to mention

Re: [Development] [EXTERNAL EMAIL] Could support for C be added to Qt?

It's really hard to imagine what SWIG's output looks like without seeing it for yourself, so I'll just post one of the outputs here. This was the shortest, most readable, and most C/C++ compatible output I could get from all the target languages available in SWIG. pastebin link

Re: [Development] [EXTERNAL EMAIL] Could support for C be added to Qt?

On Wed, Sep 14, 2022 at 5:16 PM Thiago Macieira wrote: > How about a wrapper to the wrapper? Why wrap a wrapper that wraps C++ when you can just wrap C++? Aside from the fact that it probably wouldn't be any easier, it would also start to add up the overhead of function calls. ___

Re: [Development] [EXTERNAL EMAIL] Could support for C be added to Qt?

Hi Mark, I tried SWIG, and It definitely can't be used for C. This is the interface file I tested it with: _ %module test class Test { public: Test(); Test(int); ~Test(); }; _ Every language I tried generating from that file using SWIG was betw

Re: [Development] [EXTERNAL EMAIL] Could support for C be added to Qt?

Hi Mark, Thanks for clarifying it to me. I'll read the SWIG documentation and try to get it to work before trying anything else. I'll send a reply later to tell you if it worked or not. ___ Development mailing list Development@qt-project.org https://list

Re: [Development] [EXTERNAL EMAIL] Could support for C be added to Qt?

Hi Mark, I don't think SWIG supports generating C from C++ or vice versa. Its website says it can parse to XML, but that might not be very useful since Qt is so strict on its code style rules . About the hourglass pattern, I'll put features that require more re

Re: [Development] Could support for C be added to Qt?

> Why does it need to be added to the C++ header? Why not have a fully separate > header tree? The main reason was so that C programs can include headers from the same locations as C++ can. A separate header tree is a better idea though now that I think about it. > But we'll need a proof of conce

Re: [Development] Could support for C be added to Qt?

I hadn't really thought of a plan for that, but one way it could be done is to create a program that reads the C++ headers and generates their C counterparts in a separate file, and then edit the C++ header to say something like: #ifndef __cplusplus #include "qpushbutton_c.h" #else class QPushButt

Re: [Development] Could support for C be added to Qt?

> You'll need to wrap each C++ function that you want to call with a full extern > "C" function whose body you'll generate. You need to have a C++ code parser > and a binding generator. Take a look at how the Python bindings are generated. Thanks. Would wrapping the functions make the feature too

Re: [Development] Could support for C be added to Qt?

> I believe it is not guaranteed at all that a pointer-to-member can validly > be exported as extern "C", nor how the this pointer is to be passed when you > do that. > And the C declaration from QT_C_EXPORT expands to: > void QPushButton_setFlat(bool); > which does not include a this pointer anyw

Re: [Development] Could support for C be added to Qt?

> This is something where C and C++ developers learn very different > philosophies that they have each put a lot of effort into. In C++, > casting between pointer types is considered quite dangerous if the > compiler doesn't check for human error. This is a basic concept > learned early on and adhe

Re: [Development] Could support for C be added to Qt?

> First, your own example of not having compile-time checking of the means that > those programmers are accepting less security for the sake of staying in the > same language. How? It's just the equivalent of static_cast(), and I'm talking about types with the same sizes. If the types were of diff

Re: [Development] Could support for C be added to Qt?

> Allan’s proposal to keep the code C but ensure it builds with a C++ > compiler likely had precisely this kind of scenario in mind. It does > help others to make a generic interface. It is likely a lot more work. > Experience with an AI-assisted IDE could speed things. > And what's the gain here?

Re: [Development] Could support for C be added to Qt?

> In C, constructors/destructors usually become alloc/free functions. C > has macros and code generation but these aren’t directly analogous to > templates. The problem is that C++ doesn't let you get the address of constructors/destructors. The only option might be to make a function that calls "

Re: [Development] Could support for C be added to Qt?

> To me trying to wrap the API is just a way to do things more complicated, for > the sake of making it more complicated. The programs I was thinking would benefit from something like this in particular are the ones that have been built on top of C and GTK, and would maybe like to switch now that

[Development] Could support for C be added to Qt?

Hello, I'm new to contributing to Qt directly, but I've been trying to create external C bindings for Qt for a few months now. Since C and C++ are so similar, I've recently been thinking it may just be better to add C support directly to the Qt headers by checking for the __cplusplus macro. The d