I'm using the generic wrappers and trying to use the inherited methods template example to register base class methods for derived classes. I get the following compile error when changing from asMETHOD to WRAP_MFN in the RegisterBaseMembers<> template:

error: invalid operands of types ‘<unresolved overloaded function type>’ and 'bool (MotorControl::*)()' to binary ‘operator<’

Called from:

RegisterBaseMembers<MotorControl>(engine, “MotorControl”);

In template:

template <class T> void RegisterBaseMembers(asIScriptEngine* engine, const char type)
{
    r = engine→RegisterObjectMethod(type, “bool isOn()”, WRAP_MFN(T, isOn), asCALL_GENERIC); 
                                                         ^ // ERROR
}

But, the following template compiles fine (with asMETHOD instead of WRAP_MFN):

template <class T> void RegisterBaseMembers(asIScriptEngine* engine, const char type)
{
    r = engine→RegisterObjectMethod(type, “bool isOn()”, asMETHOD(T, isOn), asCALL_THISCALL); 
}

Also, if I don't use the BaseMembers template and use the RegisterObjectMethod w/WRAP_MFN explicitly everything is fine, but becomes a maintenance nightmare for derived classes. The wrapper templates are quite complex and I'm guessing there is something about the WRAP_MFN template that is not defined when used in the RegisterBaseMembers template.

AngelScript 2.35.0 WIP
g++ 7.3.0 on Ubuntu 18.4

Looks like the g++ compiler is getting confused with the multiple < > needed to define the templates of templates that generates the code for the wrappers behind the scenes in the WRAP_MFN macro. It is reporting the error as if it is attempting to perform a comparison: “binary ‘operator<’”.

Hopefully it will be possible to solve by adding parenthesis at appropriate places, or sometimes spaces between the < > characters so the compiler can correctly interpret the result.

Can you run g++ so that only the preprocessor step is executed and show to what exactly the WRAP_MFN is expanded to in your code? I believe the command is: “g++ -E file.cc”

Sometimes you can work around the problem by using the more explicit macro WRAP_MFN _PR in which case you need to inform the method parameters and return type too.

It's true, you need to look at the preprocessed source. Add a ‘-save-temps’ to the g++ command line (maybe in CXXFLAGS, if you're using one of the well-known build systems) and look at the generated .ii file.

[SOLVED]

There is a comment in aswrappedcall.h about older versions of GNUC ( < 4.4 ) requiring an extra “template” keyword as a disambiguator and that GNUC 4.4.3 did not need it. It seems GNUC 7.3.0, doesn't need it until you start using templates in templates such as in the inherited base class template example AND using wrapper templates.

// On some versions of GNUC it is necessary to use the template keyword as disambiguator,
// on others the template keyword gives an error, hence the need for the following define.
// MSVC on the other hand seems to accept both with or without the template keyword.
#if defined(__GNUC__) && (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 4)) 
    // 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
#endif

Adding “#define TMPL template” allows the template code to pre-process with and without using inherited base class templates.

I'm not sure how you (or if) you want to handle this in the distribution b/c we only know this special case using GNUC 7.3.0. For me, I can just use #define TMPL template.

Thank you for your help (again).

I'll do some tests, but I'll probably just add a check for GNUC 7.3.0 so it also defines TMPL as template.