Re: What definition generates the SWIG upcasts in wrappers and what controls it?

Thanks William, I've managed to do that along those lines. Faking it did not work as predicted but hacking (not much) starting from shared_ptr.i I managed to create something that compiles all the way and does not crash with trivial test cases.

wbr Kusti


> On 31. Dec 2021, at 12.29, William S Fulton <[email protected]> wrote:
> 
> You've somehow got SWIG to believe that Handle_Geom_Geometry is a base class of Handle_Geom_Curve but this can't be valid (as per the compiler's error message). Given that these seem to be typedefs to a handle template, I suspect they are smart pointers and Geom_Geometry is actually a base of Geom_Curve. I suggest using SWIG's shared_ptr support to provide something similar. See https://github.com/swig/swig/blob/v4.0.2/Lib/shared_ptr.i <https://github.com/swig/swig/blob/v4.0.2/Lib/shared_ptr.i>, in particular the info at the top of that file:
> 
> // This is a helper file for shared_ptr and should not be included directly.
> 
> // The main implementation detail in using this smart pointer of a type is to customise the code generated
> // to use a pointer to the smart pointer of the type, rather than the usual pointer to the underlying type.
> // So for some type T, shared_ptr<T> * is used rather than T *.
> 
> // Another key part of the implementation is the smartptr feature:
> //   %feature("smartptr") T { shared_ptr<T> }
> // This feature marks the class T as having a smartptr to it (the shared_ptr<T> type). This is then used to
> // support smart pointers and inheritance. Say class D derives from base B, then shared_ptr<D> is marked
> // with a fake inheritance from shared_ptr<B> in the type system if the "smartptr" feature is used on both
> // B and D. This is to emulate the conversion of shared_ptr<D> to shared_ptr<B> in the target language.
> 
> William
> 
> On Sat, 25 Dec 2021 at 11:45, [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> wrote:
> 
> I'm trying to fix OpenCascade SWIG interface.
> 
> A bunch of C  wrapper functions like this:
> 
> SWIGEXPORT jlong JNICALL Java_org_jcae_opencascade_jni_OccJavaJNI_Handle_1Geom_1Curve_1SWIGUpcast(JNIEnv *jenv, jclass jcls, jlong jarg1) {
>     jlong baseptr = 0;
>     (void)jenv;
>     (void)jcls;
>     *(Handle_Geom_Geometry **)&baseptr = *(Handle_Geom_Curve **)&jarg1;
>     return baseptr;
> }
> cause errors like this:
> 
> /Users/nyholku/jCAE/occjava3/src-java/org/jcae/opencascade/jni/OccJavaJAVA_wrap.cxx:7849:42: error: incompatible pointer types assigning to 'Handle_Geom_Geometry *' (aka 'handle<Geom_Geometry> *') from 'Handle_Geom_Curve *' (aka 'handle<Geom_Curve> *')
>     *(Handle_Geom_Geometry **)&baseptr = *(Handle_Geom_Curve **)&jarg1;
> 
> on the otherhand many wrappers like this:
> 
> SWIGEXPORT jlong JNICALL Java_org_jcae_opencascade_jni_OccJavaJNI_TopoDS_1Vertex_1SWIGUpcast(JNIEnv *jenv, jclass jcls, jlong jarg1) {
>     jlong baseptr = 0;
>     (void)jenv;
>     (void)jcls;
>     *(TopoDS_Shape **)&baseptr = *(TopoDS_Vertex **)&jarg1;
>     return baseptr;
> }
> 
> compile without a problem. 
> 
> I've tried to see what is the difference in the .i files for  TopoDS / Vertex compared to Geom / Surface but can't figure it out.
> 
> What control how those SWIGupcasts are generated?
> 
> wbr Kusti
> 
> 
> 
> 
> _______________________________________________
> Swig-user mailing list
> [email protected] <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/swig-user <https://lists.sourceforge.net/lists/listinfo/swig-user>

_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user