Sono ordinati parametri non di tipo C ++ per (funzione) modelli?

Question

Sto ospitando SpiderMonkey in un progetto corrente e vorrei avere funzioni modello generare alcuni dei metodi get / set di proprietà semplici, ad esempio:

template <typename TClassImpl, int32 TClassImpl::*mem>
JSBool JS_DLL_CALLBACK WriteProp(JSContext* cx, JSObject* obj, jsval id, jsval* vp)
{
    if (TClassImpl* pImpl = (TClassImpl*)::JS_GetInstancePrivate(cx, obj, &TClassImpl::s_JsClass, NULL))
        return ::JS_ValueToInt32(cx, *vp, &(pImpl->*mem));
    return JS_FALSE;
}

Usato:

::JSPropertySpec Vec2::s_JsProps[] = {
    {"x", 1, JSPROP_PERMANENT, &JsWrap::ReadProp<Vec2, &Vec2::x>, &JsWrap::WriteProp<Vec2, &Vec2::x>},
    {"y", 2, JSPROP_PERMANENT, &JsWrap::ReadProp<Vec2, &Vec2::y>, &JsWrap::WriteProp<Vec2, &Vec2::y>},
    {0}
};

Funziona bene, tuttavia, se aggiungo un altro tipo di membro:

template <typename TClassImpl, JSObject* TClassImpl::*mem>
JSBool JS_DLL_CALLBACK WriteProp(JSContext* cx, JSObject* obj, jsval id, jsval* vp)
{
    if (TClassImpl* pImpl = (TClassImpl*)::JS_GetInstancePrivate(cx, obj, &TClassImpl::s_JsClass, NULL))
        return ::JS_ValueToObject(cx, *vp, &(pImpl->*mem));
    return JS_FALSE;
}

Quindi Visual C ++ 9 tenta di utilizzare il wrapper JSObject * per i membri int32!

1>d:\projects\testing\jswnd\src\main.cpp(93) : error C2440: 'specialization' : cannot convert from 'int32 JsGlobal::Vec2::* ' to 'JSObject *JsGlobal::Vec2::* const '
1>        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>d:\projects\testing\jswnd\src\main.cpp(93) : error C2973: 'JsWrap::ReadProp' : invalid template argument 'int32 JsGlobal::Vec2::* '
1>        d:\projects\testing\jswnd\src\wrap_js.h(64) : see declaration of 'JsWrap::ReadProp'
1>d:\projects\testing\jswnd\src\main.cpp(93) : error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'JSPropertyOp'
1>        None of the functions with this name in scope match the target type

Sorprendentemente, il parsing di JSObject * comporta un errore di analisi! (imprevisto '('). Probabilmente si tratta di un errore VC ++ (qualcuno può testare che "template void foo () {}" viene compilato in GCC?). Stesso errore con " typedef JSObject * PObject; ..., PObject TClassImpl :: mem > " ;, void , struct Undefined * e double. Poiché l'utilizzo della funzione è completamente istanziato: " & amp; ReadProp " ;, non dovrebbe entrare in gioco la semantica di sovraccarico della funzione normale , è una funzione definita a quel punto e ha la priorità sulle funzioni del modello. Sembra che qui l'ordinamento dei modelli non riesca.

Vec2 è solo:

class Vec2
{
public:
    int32 x, y;

    Vec2(JSContext* cx, JSObject* obj, uintN argc, jsval* argv);

    static ::JSClass s_JsClass;
    static ::JSPropertySpec s_JsProps[];
};

JSPropertySpec è descritto nel collegamento JSAPI in OP, preso dall'intestazione:

typedef JSBool
(* JS_DLL_CALLBACK JSPropertyOp)(JSContext *cx, JSObject *obj, jsval id,
                                 jsval *vp);

...

struct JSPropertySpec {
    const char      *name;
    int8            tinyid;
    uint8           flags;
    JSPropertyOp    getter;
    JSPropertyOp    setter;
};

Answer 1

Abbastanza sicuro che VC ++ abbia " problemi " Qui. Comeau e g ++ 4.2 sono entrambi contenti del seguente programma:

struct X
{
    int i;
    void* p;
};

template<int X::*P>
void foo(X* t)
{
    t->*P = 0;
}

template<void* X::*P>
void foo(X* t)
{
    t->*P = 0;
}

int main()
{
    X x;
    foo<&X::i>(&x);
    foo<&X::p>(&x);
}

VC ++ 2008SP1, tuttavia, non ne ha nessuna.

Non ho il tempo di leggere il mio standard per scoprire esattamente cosa ... ma penso che VC ++ sia sbagliato qui.

Answer 2

Prova a cambiare JSObject * in un altro tipo di puntatore per vedere se riproduce l'errore. JSObject è definito nel punto di utilizzo? Inoltre, forse JSObject * deve essere in parentesi.

Answer 3

Non sono certo un guru del modello, ma questo si riduce a un caso sottile di tentativo di differenziare i sovraccarichi basandosi esclusivamente sul tipo di ritorno?

Poiché C ++ non consente il sovraccarico delle funzioni in base al tipo restituito, forse la stessa cosa si applica ai parametri del modello.