05-07-2012 10:17 AM
I get the following error but only compiling for for the Device not Simulator:
..\src\main.cpp:70: error: generic thunk code fails for method 'virtual void Log::Logger:
ebug(const char*, ...)' which uses '...'\
It seems to point to the inability to use varargs in virtual functions.
I've seen some posts that this was fixed over 8 years ago in gcc 3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7618
There is also a warning: note: the mangling of 'va_list' has changed in GCC 4.4
Here's a snippet that causes the error to appear...
class ITest {
public:
~ITest() {}
virtual void Log(const char* fmt, ...) = 0;
};
class Test : public virtual ITest {
public:
Test() {}
virtual ~Test() {}
void Log(const char* fmt, ...) {}
};
int main(int argc, char** argv)
{
Test test;
test.Log("%d", 1 );
return 0;
}
05-14-2012 10:26 AM
Do you need to use multiple inheritance?
If you don't, the easiest thing to do is remove the virtual from the inheritantce line:
class Test
ublic ITest
If you do need the virtual inheritance, perhaps use a va_list in the superclass and ... only in the subclasses.
(You should also make ~ITest virtual)
05-15-2012 10:15 AM
Also, if you do want this as multiple inheritance, you probably still don't need virtual inheritance in this case.
05-15-2012 11:32 AM
Hi smacmartin,
the question is not 'what is needed and what is not' but 'why does it error out? what's wrong with this C++ code?'
Thanks.
05-15-2012 03:43 PM
Yes, some compilers do accept your code.
Nevertheless, virtual inheritance involving variable arguments is complicated for the compiler.
If you are merely defining an interface, you should not need the virtual inheritance. Just inherit non-virtually from ITest.
05-15-2012 09:15 PM
Yes i forgot the virtual on the destructor (i don't normally do that, i wish i could edit the post and fix it)
I wasn't really asking for a fix, yes i can work around it, i dont need virtual inheritance, i just was just pointing it out since i think it should work since it has in most compilers for almost a decade... (at least MS and GCC).
Isn't qcc just a wrapper on gcc 4.4? if a bug was fixed in 3.4 you'd expect it would remain fixed (well i know that bugs do reappear but this seems like the sort of thing that getst implemented and stays in the compiler...)
Anyway it isn't a showstopper or anything, it was more a curosity I though i'd point out...
05-16-2012 10:59 AM
Bug report created: