Fixing `-Wincompatible-pointer-types` compiler warning
-
@kshegunov I'll try that tomorrow. Sounds like a clever, reuseable, and clean macro solution :)
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
and clean macro solution
As much as such a thing exists ;P
Read and abide by the Qt Code of Conduct
-
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
and clean macro solution
As much as such a thing exists ;P
@kshegunov It doesn't - But in C it's the only possibility ;)
-
I don't understand. The typedef/macro is a single one for the type of the table elements, not the type(s) of the functions (which could vary) you put in it? So if you have one "the real table" I don't see why you want 20 typedefs?
The real table looks like this:
typedef struct Table { bool init(void *); bool setParam1(void *, bool param); bool param1(void *); bool setParam2(void *, bool param); bool param2(void *); bool write(void *, uint32_t value); uint32_t read(void *, bool *ok); // ... } Table;So you need to have typedefs for each function prototype. Some might be reuseable, but probably it's better to have one for each row.
Since presumably you have just one table initialisation in one
No, I have a handful implementations of that.
@kshegunov idea of having a macro to create all the tables sounds great, I'll need to try that.
Thanks for your help
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
The real table looks like this:
Yes, sorry, I edited my earlier post, I quite misunderstood and thought you had an array of function pointers to which you wanted to assign.
But now there is something odd in your case. Since you have
The real table looks like this:
typedef struct Table { bool init(void *); bool setParam1(void *, bool param);that implies you are writing out exactly the required signature for each function pointer in the
struct. In which case, why don't they match correctly against the functions you are assigning to them, then you wouldn't need casts...? That is why I was thinking of the array-of-function-pointers situation, where you do have a problem with one array element type and mutiple different function types to assign. -
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
The real table looks like this:
Yes, sorry, I edited my earlier post, I quite misunderstood and thought you had an array of function pointers to which you wanted to assign.
But now there is something odd in your case. Since you have
The real table looks like this:
typedef struct Table { bool init(void *); bool setParam1(void *, bool param);that implies you are writing out exactly the required signature for each function pointer in the
struct. In which case, why don't they match correctly against the functions you are assigning to them, then you wouldn't need casts...? That is why I was thinking of the array-of-function-pointers situation, where you do have a problem with one array element type and mutiple different function types to assign.As @kshegunov already wrote, the first pointer, the
void *is specialized for each implementation struct - think of inheritance.So the "base class" has
void *and the implementations haveFoo *resp.Bar *.Nothing wrong with that, just that the compiler warns at this point (which is a bit pointless imho, as ever pointer is compatible to
void *, but ok.Regards
Qt has to stay free or it will die.
-
As @kshegunov already wrote, the first pointer, the
void *is specialized for each implementation struct - think of inheritance.So the "base class" has
void *and the implementations haveFoo *resp.Bar *.Nothing wrong with that, just that the compiler warns at this point (which is a bit pointless imho, as ever pointer is compatible to
void *, but ok.Regards
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
Nothing wrong with that, just that the compiler warns at this point (which is a bit pointless imho, as ever pointer is compatible to void *, but ok.
Yes, every pointer decays implicitly to
void *, but that's not what the compiler whines about. It complains because the function prototypes are different, hence the actual functions may be different, the compiler can't tell out of the box. -
As @kshegunov already wrote, the first pointer, the
void *is specialized for each implementation struct - think of inheritance.So the "base class" has
void *and the implementations haveFoo *resp.Bar *.Nothing wrong with that, just that the compiler warns at this point (which is a bit pointless imho, as ever pointer is compatible to
void *, but ok.Regards
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
So the "base class" has
void *and the implementations haveFoo *resp.Bar *.What I don't get is: if these classes do not share some base class (
Foo,Bar, or something else), it's a bit hard to think what you're doing in C++ to either of them as a parameter to a function when all they have in common is they are pointers to something unknown?You don't have to answer/justify yourself. I realise you doubtless know what you are doing and have your own reasons. But that's what strikes me.
-
@aha_1980 said in Fixing `-Wincompatible-pointer-types` compiler warning:
So the "base class" has
void *and the implementations haveFoo *resp.Bar *.What I don't get is: if these classes do not share some base class (
Foo,Bar, or something else), it's a bit hard to think what you're doing in C++ to either of them as a parameter to a function when all they have in common is they are pointers to something unknown?You don't have to answer/justify yourself. I realise you doubtless know what you are doing and have your own reasons. But that's what strikes me.
@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
What I don't get is: if these classes do not share some base class (Foo, Bar, or something else), it's a bit hard to think what you're doing in C++ to either of them as a parameter to a function when all they have in common is they are pointers to something unknown?
What is a base class in C?
Read and abide by the Qt Code of Conduct
-
@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
What I don't get is: if these classes do not share some base class (Foo, Bar, or something else), it's a bit hard to think what you're doing in C++ to either of them as a parameter to a function when all they have in common is they are pointers to something unknown?
What is a base class in C?
@kshegunov said in Fixing `-Wincompatible-pointer-types` compiler warning:
What is a base class in C?
Oh damn! I forgot already this is not C++, sorry... !
OK, well, I still wonder what the shared function does being handed pointers to different C
structs, when you don't know whatstructit is...? -
@kshegunov said in Fixing `-Wincompatible-pointer-types` compiler warning:
What is a base class in C?
Oh damn! I forgot already this is not C++, sorry... !
OK, well, I still wonder what the shared function does being handed pointers to different C
structs, when you don't know whatstructit is...?@JonB said in Fixing `-Wincompatible-pointer-types` compiler warning:
OK, well, I still wonder what the shared function does being handed pointers to different C
structs, when you don't know whatstructit is...?Well, as far as I understood the task the point is to allow inheritance support for a language (and a compiler) which doesn't provide it. This entails (if you follow what C++ does) having a static table of methods for each "class". Each "inherited" table then is supposedly referencing the base class' table and further allowing it to be extended. And if you want at the end you can get dynamic polymorphism in. All in all it's not a trivial thing to do, but should be doable with some magic.
-
@fcarney said in Fixing `-Wincompatible-pointer-types` compiler warning:
Makes me wonder if there is a C++ "like" preprocessor that can produce C.
cmake can produce code (even source I think), and of course you can write your own preprocessor if you wish ... :D
-
Apparently there is: https://isocpp.org/wiki/faq/compiler-dependencies#convert-to-c
@fcarney said in Fixing `-Wincompatible-pointer-types` compiler warning:
Apparently there is: https://isocpp.org/wiki/faq/compiler-dependencies#convert-to-c
heh, that's an interesting find ... and sort of a funny one ...
