Re: [Swig-user] Missing swigCMemOwn in Java wrappings

[Oliver B. <oli...@jk...>]

Am 09.02.2011 14:21, schrieb Payton Oliveri (CONTR):
> Hi,
>
> I'm having trouble getting SWIG to wrap a C++ class I have into Java.
> It's not creating swigCMemOwn, and I'm not sure whether it's related to
> ignoring the second parent of a multiply inherited class or if its
> something I'm doing in my inheritance hierarchy.
>
> I have a template class that inherits from both a non-template class,
> and another templated class, something like this:
> template<class T>
> class Item : public ParentItem, public boost::enable_shared_from_this<T>
> {
> protected:
>      Item(){}
>      ~Item(){}
> public:
>      boost::shared_ptr<T>  GetSharedFromThis() {return
> boost::enable_shared_from_this<T>::shared_from_this();}
> };
>
> This class then has children, which are all defined like:
> class ChildItemA : public Item<ChildItemA>
>
> For each child class, I define templates. (Because these templates are
> only relevant if inheriting from the second parent as well, I tried to
> wrap these in an #ifdef SWIGPYTHON but it warned that I had neglected to
> define them with %template.):
> %template(enable_shared_from_this_ChildA)
> boost::enable_shared_from_this<ChildItemA>;
> %template(Item_ChildA) Item<ChildItemA>;
>
> This build successfully in C++ and under Python, but under Java it does
> give warnings and errors for each child class. (I got rid of some of the
> long path name stuff so it was easier to read).
> 1) Using the non const-declared version of method -- don't think this is
> related, but included just in case
> Warning 516: Overloaded method boost::enable_shared_from_this<
> ChildItemA>::shared_from_this() const ignored,
> Warning 516: using boost::enable_shared_from_this<  ChildItemA
>> ::shared_from_this() instead.
> 2) Multiple inheritance, which is not surprising
> Warning for Item<  ChildItemA>  proxy: Base
> boost::enable_shared_from_this<  ChildItemA>  ignored. Multiple
> inheritance is not supported in Java.
> 3) Later, when building the .jar
> Item_ChildA.java:25: cannot find symbol
> symbol  : variable swigCMemOwn
> location: class Item_ChildItemA
>        if (swigCMemOwn) {
>            ^
> Item_ChildA.java:26: cannot find symbol
> symbol  : variable swigCMemOwn
> location: class Item_ChildItemA
>          swigCMemOwn = false;
>
>
> All of these errors appear in the delete function in
> Item_ChildItemX.java, which references the ownership flag (although the
> flag has not been declared alongside swigCPtr):
>    public synchronized void delete() {
>      if (swigCPtr != 0) {
>        if (swigCMemOwn) {
>          swigCMemOwn = false;
>          throw new UnsupportedOperationException("C++ destructor does not
> have public access");
>        }
>        swigCPtr = 0;
>      }
>      super.delete();
>    }
>
> I've played around with modifying the visibility of the constructor and
> destructor, wondering if somehow SWIG was confused as to whether or not
> it should or shouldn't track whether or not to delete this class, and no
> combination of public and protected seems to work out. My thinking is
> that objects of type Item_ChildX shouldn't be created anyway, as they
> are somewhat analogous to abstract classes in C++, though I may be
> mistaken. Is there a correct way to inform SWIG how to convert these
> classes correctly or to avoid having to define/create them at all, as
> the multiple inheritance component that necessitates them should be ignored?
>
> Thanks!
> Payton Oliveri
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Swig-user mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-user
Hi,

I had such problems when using the %shared_ptr macro.
I had to declare it for every each parent class in a hierarchy and this 
error resolved.
though, don't know if this applies to your case too...

Bye,
Oliver

don't know if this applies to