Open HGuillemet opened 1 year ago
It won't work if class D isn't Virtual as well, yes, that's expected.
Actually, that probably wouldn't work either. That sounds like the kind of thing your Info.upcast is supposed to solve...
D
is already virtual, since inherits a virtual function.
The point ofupcast
is to introduce static_cast or dynamic_cast when C cast doesn't work. That's not the case here. Look at my 2 suggestions at the end of the post. Doesn't one of them sound sane ?
A workaround, as long as we don't need D
to be virtualized, is to add, like for torch::Module
:
infoMap.put(new Info("B::f").annotations("@Virtual(subclasses=false)")
This prevents the JavaCPP_D
peer class to be created.
This triggers an infinite recursion:
d.f
is called.f
is not overridden in Java, so JavaB.f
is calledJava_B_f
is called. SinceB
is virtualized, instead of calling C++B::f
, the object is checked whether if's an instance of the peer classJavaCPP_B
. It's not the case, the object is aJavaCPP_D
, andJavaCPP_D
doesn't derive fromJavaCPP_B
. Sof
is called on the object, that isJavaCPP_D::f
.JavaCPP_D::f
calls Javad.f
.How to solve this ? Shouldn't
JavaCPP_D
derives fromJavaCPP_B
in addition of deriving fromD
? Or should we call explicityB::f
and bypass dynamic invocation at the end of 2. ?