> 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
samuel ammonius wrote:
> Would wrapping the functions make the feature too large to be approved for
> Qt?
I do not see why you want this to be "approved for Qt" to begin with. I
think it is much more practical to keep the C bindings separate, just as all
the other language bindings out there.
E
On Sunday, 11 September 2022 09:50:13 PDT samuel ammonius wrote:
> 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,
Please take a look at existing binding generators
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
On Sunday, 11 September 2022 09:13:53 PDT samuel ammonius wrote:
> Would wrapping the functions make the feature too large to be approved for
> Qt?
> I'm not sure how large something like that would be in terms of storage
> space.
Storage space is not the problem. Git repositories are relatively c
> 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
On Sunday, 11 September 2022 07:45:18 PDT samuel ammonius wrote:
> I assumed that the C++ standard said that the first parameter of a function
> would be "this".
It doesn't. On at least one ABI, the this pointer is passed in a different
register than the first parameter.
In any case, you can't d
Karl Semich wrote:
> C bindings are often needed to link with other languages that
> recognise only C linker symbols, or with codebases designed to run on
> embedded systems with no C++ compiler targeting them.
How would you port Qt to those systems?
Kevin Kofler
samuel ammonius wrote:
> I made a mistake in my example of QPushButton_setFlat(). the parameters
> should have been (QPushButton *, bool) instead of just (bool).
But then you probably need to rewrite QT_C_EXPORT as a variadic macro,
unless you want to pass the parameter list twice, because the PA
samuel ammonius wrote:
> What kind of human error would make converting between the
> pointers dangerous? I've never understood the point of C++
> making pointer types incompatible and then introducing templates
> to bypass this by making a new function for each pointer.
Templates in C++ are much
> 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
samuel ammonius wrote:
> In the qtc project I linked to earlier, I managed to implement function
> overloading in C using vardiac macro functions that would find the number
> of parameters and add that number to the end of the function. For example,
> QPushButton() would become QPushButton0(), and
samuel ammonius wrote:
> 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 __
13 matches
Mail list logo
