-
We are investigating using javacpp and moving away from swig. We have a base class that intentionally has a protected destructor. class Object_I {
protected :
inline virtual ~Object_I() = 0;
};
inline Object_I::~Object_I() {
} Inherited by many classes including the following: class Child_T : public Object_I {
public :
long time;
}; results in the following error: jnicommon.cpp: In function ‘void JavaCPP_common_00024Object_1I_deallocate(void*)’:
jnicommon.cpp:371:123: error: ‘virtual Object_I::~Object_I()’ is protected within this context
static void JavaCPP_common_00024Object_1I_deallocate(void *p) { delete (Object_I*)p; }
^
In file included from jnicommon.cpp:102:
Object_I.h:35:16: note: declared protected here
inline Object_I::~Object_I() { This is how swig decided to deal with the Object_I with its code generation: public class Object_I {
private long swigCPtr;
protected boolean swigCMemOwn;
public Object_I(long cPtr, boolean cMemoryOwn) {
swigCMemOwn = cMemoryOwn;
swigCPtr = cPtr;
}
public static long getCPtr(Object_I obj) {
return (obj == null) ? 0 : obj.swigCPtr;
}
public synchronized void delete() {
if (swigCPtr != 0) {
if (swigCMemOwn) {
swigCMemOwn = false;
throw new UnsupportedOperationException("C++ destructor does not have public access");
}
swigCPtr = 0;
}
}
} What would be the best way to handle this in javacpp? |
Beta Was this translation helpful? Give feedback.
Answered by
peskygnat
Oct 15, 2024
Replies: 1 comment 1 reply
-
We can annotate the constructor with |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since the class is complete abstract other than the destructor, this seems to be the easy solution in the Config.