Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Also this fix:
// original
//#if defined(__GNUC__) && (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 4))
// Fixed for MinGW
#if defined(__GNUC__)
// GNUC 4.4.3 doesn't need the template keyword, and
// hopefully upcoming versions won't need it either
#define TMPL template
#else
#define TMPL
#endifHttpRequest is derived from Deserializer
Works:
static String HttpRequest_String_ReadLine_void(HttpRequest* _ptr)
{
String result = _ptr->ReadLine();
return result;
}
engine->RegisterObjectMethod("HttpRequest", "String ReadLine()", asFUNCTION(HttpRequest_String_ReadLine_void), asCALL_CDECL_OBJFIRST);Crash:
static String HttpRequest_String_ReadLine_void(Deserializer* _ptr)
{
String result = _ptr->ReadLine();
return result;
}
engine->RegisterObjectMethod("HttpRequest", "String ReadLine()", asFUNCTION(HttpRequest_String_ReadLine_void), asCALL_CDECL_OBJFIRST);But Deserializer* and HttpRequest* are the same in memory. Or not?
1vanK said:
But Deserializer* and HttpRequest* are the same in memory. Or not?
Not necessarily. If HttpRequest inherits from other classes too besides the Deserialization then the pointer may be different when refering to the object as HttpRequest vs Deserialization.
I'll look into the proposed fixes for the auto wrappers.
I've check in your fix for WRAP_MFN_PR on MSVC.
Unfortunately I haven't been able to find a solution for this on gnuc compilers. I think it may be a bug/limitation in the gnuc compiler itself.
