From: William S Fulton <wsf@fu...>  20140410 19:47:21

It's not clear how the memory management will work. What will the wrappers look like for : %newobject SquareFactory; Square *SquareFactory() { return new Square(10); } Factory *Grab() { static Square local(20); return &local; } William On 10/04/14 10:44, Joel Andersson wrote: > For reference, I updated the code and added support for inheritance and > multiple inheritance (diamond problem avoided by adding a swigRef ABC): > https://gist.github.com/jaeandersson/10169322 > > Regards, > Joel > > > > 20140410 9:43 GMT+02:00 Joel Andersson <j.a.e.andersson@... > <mailto:j.a.e.andersson@...>>: > > Hi! > > Thank you a lot for your feedback. > > I _am_ using the work of Josef et al but I decided that it was > easier for me to copy/adapt the parts I need rather than going > through the frustration of debugging and extended a code I don't > fully understand. At the same time, there are some fundamental > issues with their approach that I want to resolve. My interest in > this is that we need a MATLAB interface to our software project (for > which we already use SWIG). I want to make sure that this interface > is going to be essentially as good as a handwritten interface. If > this is not a possible outcome of my work, I'd rather just keep > directing users to the Python interface. > > What is the fundamental problem with the single entry approach? The > string identifier can of course be replaced by an integer index and > the "ifelse ifelse if else" block be replaced by an C++ switch, > which should compile to a lookup table. Is it then still > inefficient? MATLAB MEX functions, which is the preferred way of > interfacing C code, only have a single entry point. > > I'll update the names of "h" and "this" as suggested. > > The ownership of the C++ class is achieved by inheriting from the > "handle" class. That turns the MATLAB class into a referencecounted > object and copying is always by reference. The "delete" member > function is MATLAB's way of declaring a destructor, called upon > destruction. > > Inheritance relation will be added, the only issue is that I still > need to figure out how to avoid multiple copies of the 'h' property > in the case of multiple inheritance. > > Greetings and thanks! > > Joel > > > On Apr 10, 2014 8:16 AM, "William S Fulton" <wsf@... > <mailto:wsf@...>> wrote: > > On 08/04/14 20:34, Joel Andersson wrote: > > Hello! > > I did some work on a MATLAB module in my SWIG fork > (https://github.com/__jaeandersson/swig/tree/matlab > <https://github.com/jaeandersson/swig/tree/matlab>)__. I had > look at Josef > Pacula's work (https://github.com/twiho/__MatlabinSWIG > <https://github.com/twiho/MatlabinSWIG>;) and the master > theses of him and his colleage, but in the end I decided to > start with a > cleansheet design. Although I advocated using MATLAB's > ability to call > C shared libraries (via loadlibrary, calllib) earlier, in > the end I > think the safest and userfriendliest is to let all the > calls for a SWIG > module go through one MEXfunction. > > I uploaded some MATLAB interface code for the "class" > example in SWIG. > The code is incomplete, but the message should come across: > https://gist.github.com/__jaeandersson/10169322/ > <https://gist.github.com/jaeandersson/10169322/>; > > My plan was to let C/C++ pointers be stored in MATLAB by doing a > reinterpret_cast to a 64bit unsigned int (uint64_t). This > was suggested > and has been tested in the following (nonSWIG) example on > how to > interface C++ with MATLAB: > http://www.mathworks.com/__matlabcentral/fileexchange/__38964examplematlabclass__wrapperforac++class > <http://www.mathworks.com/matlabcentral/fileexchange/38964examplematlabclasswrapperforac++class>;. > > I would be happy to get some feedback on this draft. Also, > if someone is > interested in cooperating on this, please let me know. I am > not sure if > I have the time/resources to finish the module on my own. > > Hi Joel > > What are the essential problems for not using the previous work > of Josef Pacula et al? It would be a shame to have another half > finished module if you don't have the resources to finish this > new one. > > Using a single entry method sounds rather inefficient for any > reasonable sized module. Why not use multiple entry points like > the other languages? They can be generated easily. > > The 'h' property is cryptic to say the least. I would mangle it > and give it a sensible name. In Java it is called swigCPtr. > Unless 'this' means something special in Matlab, call it 'self' > as that is the naming used throughout SWIG. I don't see anything > around ownership of the underlying C++ class pointers. I would > take a look at the Java module  swigCMemOwn. I don't see any > inheritance relationship between the Matlab Shape and Square > classes, is that in the pipeline? > > William > > > > >  > >  > Joel Andersson > Ptge. Busquets 1113, atico 3 > E08940 Cornella de Llobregat, Spain > Home: +34936034011 > Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / > +46707360512 (Sweden) 
From: Joel Andersson <j.andersson@gm...>  20140408 19:34:55
Attachments:
Message as HTML

Hello! I did some work on a MATLAB module in my SWIG fork ( https://github.com/jaeandersson/swig/tree/matlab). I had look at Josef Pacula's work (https://github.com/twiho/MatlabinSWIG) and the master theses of him and his colleage, but in the end I decided to start with a cleansheet design. Although I advocated using MATLAB's ability to call C shared libraries (via loadlibrary, calllib) earlier, in the end I think the safest and userfriendliest is to let all the calls for a SWIG module go through one MEXfunction. I uploaded some MATLAB interface code for the "class" example in SWIG. The code is incomplete, but the message should come across: https://gist.github.com/jaeandersson/10169322/ My plan was to let C/C++ pointers be stored in MATLAB by doing a reinterpret_cast to a 64bit unsigned int (uint64_t). This was suggested and has been tested in the following (nonSWIG) example on how to interface C++ with MATLAB: http://www.mathworks.com/matlabcentral/fileexchange/38964examplematlabclasswrapperforac++class . I would be happy to get some feedback on this draft. Also, if someone is interested in cooperating on this, please let me know. I am not sure if I have the time/resources to finish the module on my own. Best regards! Joel   Joel Andersson Ptge. Busquets 1113, atico 3 E08940 Cornella de Llobregat, Spain Home: +34936034011 Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / +46707360512 (Sweden) 
From: William S Fulton <wsf@fu...>  20140410 06:16:09

On 08/04/14 20:34, Joel Andersson wrote: > Hello! > > I did some work on a MATLAB module in my SWIG fork > (https://github.com/jaeandersson/swig/tree/matlab). I had look at Josef > Pacula's work (https://github.com/twiho/MatlabinSWIG) and the master > theses of him and his colleage, but in the end I decided to start with a > cleansheet design. Although I advocated using MATLAB's ability to call > C shared libraries (via loadlibrary, calllib) earlier, in the end I > think the safest and userfriendliest is to let all the calls for a SWIG > module go through one MEXfunction. > > I uploaded some MATLAB interface code for the "class" example in SWIG. > The code is incomplete, but the message should come across: > https://gist.github.com/jaeandersson/10169322/ > > My plan was to let C/C++ pointers be stored in MATLAB by doing a > reinterpret_cast to a 64bit unsigned int (uint64_t). This was suggested > and has been tested in the following (nonSWIG) example on how to > interface C++ with MATLAB: > http://www.mathworks.com/matlabcentral/fileexchange/38964examplematlabclasswrapperforac++class. > > I would be happy to get some feedback on this draft. Also, if someone is > interested in cooperating on this, please let me know. I am not sure if > I have the time/resources to finish the module on my own. > Hi Joel What are the essential problems for not using the previous work of Josef Pacula et al? It would be a shame to have another half finished module if you don't have the resources to finish this new one. Using a single entry method sounds rather inefficient for any reasonable sized module. Why not use multiple entry points like the other languages? They can be generated easily. The 'h' property is cryptic to say the least. I would mangle it and give it a sensible name. In Java it is called swigCPtr. Unless 'this' means something special in Matlab, call it 'self' as that is the naming used throughout SWIG. I don't see anything around ownership of the underlying C++ class pointers. I would take a look at the Java module  swigCMemOwn. I don't see any inheritance relationship between the Matlab Shape and Square classes, is that in the pipeline? William 
From: Joel Andersson <j.andersson@gm...>  20140410 07:44:01
Attachments:
Message as HTML

Hi! Thank you a lot for your feedback. I _am_ using the work of Josef et al but I decided that it was easier for me to copy/adapt the parts I need rather than going through the frustration of debugging and extended a code I don't fully understand. At the same time, there are some fundamental issues with their approach that I want to resolve. My interest in this is that we need a MATLAB interface to our software project (for which we already use SWIG). I want to make sure that this interface is going to be essentially as good as a handwritten interface. If this is not a possible outcome of my work, I'd rather just keep directing users to the Python interface. What is the fundamental problem with the single entry approach? The string identifier can of course be replaced by an integer index and the "ifelse ifelse if else" block be replaced by an C++ switch, which should compile to a lookup table. Is it then still inefficient? MATLAB MEX functions, which is the preferred way of interfacing C code, only have a single entry point. I'll update the names of "h" and "this" as suggested. The ownership of the C++ class is achieved by inheriting from the "handle" class. That turns the MATLAB class into a referencecounted object and copying is always by reference. The "delete" member function is MATLAB's way of declaring a destructor, called upon destruction. Inheritance relation will be added, the only issue is that I still need to figure out how to avoid multiple copies of the 'h' property in the case of multiple inheritance. Greetings and thanks! Joel On Apr 10, 2014 8:16 AM, "William S Fulton" <wsf@...> wrote: > On 08/04/14 20:34, Joel Andersson wrote: > >> Hello! >> >> I did some work on a MATLAB module in my SWIG fork >> (https://github.com/jaeandersson/swig/tree/matlab). I had look at Josef >> Pacula's work (https://github.com/twiho/MatlabinSWIG) and the master >> theses of him and his colleage, but in the end I decided to start with a >> cleansheet design. Although I advocated using MATLAB's ability to call >> C shared libraries (via loadlibrary, calllib) earlier, in the end I >> think the safest and userfriendliest is to let all the calls for a SWIG >> module go through one MEXfunction. >> >> I uploaded some MATLAB interface code for the "class" example in SWIG. >> The code is incomplete, but the message should come across: >> https://gist.github.com/jaeandersson/10169322/ >> >> My plan was to let C/C++ pointers be stored in MATLAB by doing a >> reinterpret_cast to a 64bit unsigned int (uint64_t). This was suggested >> and has been tested in the following (nonSWIG) example on how to >> interface C++ with MATLAB: >> http://www.mathworks.com/matlabcentral/fileexchange/ >> 38964examplematlabclasswrapperforac++class. >> >> I would be happy to get some feedback on this draft. Also, if someone is >> interested in cooperating on this, please let me know. I am not sure if >> I have the time/resources to finish the module on my own. >> >> Hi Joel > > What are the essential problems for not using the previous work of Josef > Pacula et al? It would be a shame to have another half finished module if > you don't have the resources to finish this new one. > > Using a single entry method sounds rather inefficient for any reasonable > sized module. Why not use multiple entry points like the other languages? > They can be generated easily. > > The 'h' property is cryptic to say the least. I would mangle it and give > it a sensible name. In Java it is called swigCPtr. Unless 'this' means > something special in Matlab, call it 'self' as that is the naming used > throughout SWIG. I don't see anything around ownership of the underlying > C++ class pointers. I would take a look at the Java module  swigCMemOwn. I > don't see any inheritance relationship between the Matlab Shape and Square > classes, is that in the pipeline? > > William > > 
From: Joel Andersson <j.andersson@gm...>  20140410 09:44:38
Attachments:
Message as HTML

For reference, I updated the code and added support for inheritance and multiple inheritance (diamond problem avoided by adding a swigRef ABC): https://gist.github.com/jaeandersson/10169322 Regards, Joel 20140410 9:43 GMT+02:00 Joel Andersson <j.a.e.andersson@...>: > Hi! > > Thank you a lot for your feedback. > > I _am_ using the work of Josef et al but I decided that it was easier for > me to copy/adapt the parts I need rather than going through the frustration > of debugging and extended a code I don't fully understand. At the same > time, there are some fundamental issues with their approach that I want to > resolve. My interest in this is that we need a MATLAB interface to our > software project (for which we already use SWIG). I want to make sure that > this interface is going to be essentially as good as a handwritten > interface. If this is not a possible outcome of my work, I'd rather just > keep directing users to the Python interface. > > What is the fundamental problem with the single entry approach? The string > identifier can of course be replaced by an integer index and the "ifelse > ifelse if else" block be replaced by an C++ switch, which should compile > to a lookup table. Is it then still inefficient? MATLAB MEX functions, > which is the preferred way of interfacing C code, only have a single entry > point. > > I'll update the names of "h" and "this" as suggested. > > The ownership of the C++ class is achieved by inheriting from the "handle" > class. That turns the MATLAB class into a referencecounted object and > copying is always by reference. The "delete" member function is MATLAB's > way of declaring a destructor, called upon destruction. > > Inheritance relation will be added, the only issue is that I still need to > figure out how to avoid multiple copies of the 'h' property in the case of > multiple inheritance. > > Greetings and thanks! > > Joel > > > On Apr 10, 2014 8:16 AM, "William S Fulton" <wsf@...> > wrote: > >> On 08/04/14 20:34, Joel Andersson wrote: >> >>> Hello! >>> >>> I did some work on a MATLAB module in my SWIG fork >>> (https://github.com/jaeandersson/swig/tree/matlab). I had look at Josef >>> Pacula's work (https://github.com/twiho/MatlabinSWIG) and the master >>> theses of him and his colleage, but in the end I decided to start with a >>> cleansheet design. Although I advocated using MATLAB's ability to call >>> C shared libraries (via loadlibrary, calllib) earlier, in the end I >>> think the safest and userfriendliest is to let all the calls for a SWIG >>> module go through one MEXfunction. >>> >>> I uploaded some MATLAB interface code for the "class" example in SWIG. >>> The code is incomplete, but the message should come across: >>> https://gist.github.com/jaeandersson/10169322/ >>> >>> My plan was to let C/C++ pointers be stored in MATLAB by doing a >>> reinterpret_cast to a 64bit unsigned int (uint64_t). This was suggested >>> and has been tested in the following (nonSWIG) example on how to >>> interface C++ with MATLAB: >>> http://www.mathworks.com/matlabcentral/fileexchange/ >>> 38964examplematlabclasswrapperforac++class. >>> >>> I would be happy to get some feedback on this draft. Also, if someone is >>> interested in cooperating on this, please let me know. I am not sure if >>> I have the time/resources to finish the module on my own. >>> >>> Hi Joel >> >> What are the essential problems for not using the previous work of Josef >> Pacula et al? It would be a shame to have another half finished module if >> you don't have the resources to finish this new one. >> >> Using a single entry method sounds rather inefficient for any reasonable >> sized module. Why not use multiple entry points like the other languages? >> They can be generated easily. >> >> The 'h' property is cryptic to say the least. I would mangle it and give >> it a sensible name. In Java it is called swigCPtr. Unless 'this' means >> something special in Matlab, call it 'self' as that is the naming used >> throughout SWIG. I don't see anything around ownership of the underlying >> C++ class pointers. I would take a look at the Java module  swigCMemOwn. I >> don't see any inheritance relationship between the Matlab Shape and Square >> classes, is that in the pipeline? >> >> William >> >>   Joel Andersson Ptge. Busquets 1113, atico 3 E08940 Cornella de Llobregat, Spain Home: +34936034011 Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / +46707360512 (Sweden) 
From: William S Fulton <wsf@fu...>  20140410 19:47:21

It's not clear how the memory management will work. What will the wrappers look like for : %newobject SquareFactory; Square *SquareFactory() { return new Square(10); } Factory *Grab() { static Square local(20); return &local; } William On 10/04/14 10:44, Joel Andersson wrote: > For reference, I updated the code and added support for inheritance and > multiple inheritance (diamond problem avoided by adding a swigRef ABC): > https://gist.github.com/jaeandersson/10169322 > > Regards, > Joel > > > > 20140410 9:43 GMT+02:00 Joel Andersson <j.a.e.andersson@... > <mailto:j.a.e.andersson@...>>: > > Hi! > > Thank you a lot for your feedback. > > I _am_ using the work of Josef et al but I decided that it was > easier for me to copy/adapt the parts I need rather than going > through the frustration of debugging and extended a code I don't > fully understand. At the same time, there are some fundamental > issues with their approach that I want to resolve. My interest in > this is that we need a MATLAB interface to our software project (for > which we already use SWIG). I want to make sure that this interface > is going to be essentially as good as a handwritten interface. If > this is not a possible outcome of my work, I'd rather just keep > directing users to the Python interface. > > What is the fundamental problem with the single entry approach? The > string identifier can of course be replaced by an integer index and > the "ifelse ifelse if else" block be replaced by an C++ switch, > which should compile to a lookup table. Is it then still > inefficient? MATLAB MEX functions, which is the preferred way of > interfacing C code, only have a single entry point. > > I'll update the names of "h" and "this" as suggested. > > The ownership of the C++ class is achieved by inheriting from the > "handle" class. That turns the MATLAB class into a referencecounted > object and copying is always by reference. The "delete" member > function is MATLAB's way of declaring a destructor, called upon > destruction. > > Inheritance relation will be added, the only issue is that I still > need to figure out how to avoid multiple copies of the 'h' property > in the case of multiple inheritance. > > Greetings and thanks! > > Joel > > > On Apr 10, 2014 8:16 AM, "William S Fulton" <wsf@... > <mailto:wsf@...>> wrote: > > On 08/04/14 20:34, Joel Andersson wrote: > > Hello! > > I did some work on a MATLAB module in my SWIG fork > (https://github.com/__jaeandersson/swig/tree/matlab > <https://github.com/jaeandersson/swig/tree/matlab>)__. I had > look at Josef > Pacula's work (https://github.com/twiho/__MatlabinSWIG > <https://github.com/twiho/MatlabinSWIG>;) and the master > theses of him and his colleage, but in the end I decided to > start with a > cleansheet design. Although I advocated using MATLAB's > ability to call > C shared libraries (via loadlibrary, calllib) earlier, in > the end I > think the safest and userfriendliest is to let all the > calls for a SWIG > module go through one MEXfunction. > > I uploaded some MATLAB interface code for the "class" > example in SWIG. > The code is incomplete, but the message should come across: > https://gist.github.com/__jaeandersson/10169322/ > <https://gist.github.com/jaeandersson/10169322/>; > > My plan was to let C/C++ pointers be stored in MATLAB by doing a > reinterpret_cast to a 64bit unsigned int (uint64_t). This > was suggested > and has been tested in the following (nonSWIG) example on > how to > interface C++ with MATLAB: > http://www.mathworks.com/__matlabcentral/fileexchange/__38964examplematlabclass__wrapperforac++class > <http://www.mathworks.com/matlabcentral/fileexchange/38964examplematlabclasswrapperforac++class>;. > > I would be happy to get some feedback on this draft. Also, > if someone is > interested in cooperating on this, please let me know. I am > not sure if > I have the time/resources to finish the module on my own. > > Hi Joel > > What are the essential problems for not using the previous work > of Josef Pacula et al? It would be a shame to have another half > finished module if you don't have the resources to finish this > new one. > > Using a single entry method sounds rather inefficient for any > reasonable sized module. Why not use multiple entry points like > the other languages? They can be generated easily. > > The 'h' property is cryptic to say the least. I would mangle it > and give it a sensible name. In Java it is called swigCPtr. > Unless 'this' means something special in Matlab, call it 'self' > as that is the naming used throughout SWIG. I don't see anything > around ownership of the underlying C++ class pointers. I would > take a look at the Java module  swigCMemOwn. I don't see any > inheritance relationship between the Matlab Shape and Square > classes, is that in the pipeline? > > William > > > > >  > >  > Joel Andersson > Ptge. Busquets 1113, atico 3 > E08940 Cornella de Llobregat, Spain > Home: +34936034011 > Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / > +46707360512 (Sweden) 
From: Joel Andersson <j.andersson@gm...>  20140411 07:48:30
Attachments:
Message as HTML

OK, I will have to look into that. I guess you would need to add a data member indicating ownership to my SwigRef MATLAB class (the ABC holding the pointer). Or do you have some other suggestion? In the public API of the software I need a MATLAB interface for we work almost exclusively with reference counted objects, no pointers. So I didn't give this much thought. Anyway, I think I would prefer to focus on getting a complete working wrapper for the "class" example and only then move on to more advanced examples. I must say that the programming has been going quite smoothly. Many things can be taken with little modifications from the Octave module (Octave being essentially a MATLAB clone). Regards, Joel 20140410 21:24 GMT+02:00 William S Fulton <wsf@...>: > It's not clear how the memory management will work. What will the wrappers > look like for : > > %newobject SquareFactory; > Square *SquareFactory() { return new Square(10); } > > Factory *Grab() { static Square local(20); return &local; } > > William > > > On 10/04/14 10:44, Joel Andersson wrote: > >> For reference, I updated the code and added support for inheritance and >> multiple inheritance (diamond problem avoided by adding a swigRef ABC): >> https://gist.github.com/jaeandersson/10169322 >> >> Regards, >> Joel >> >> >> >> 20140410 9:43 GMT+02:00 Joel Andersson <j.a.e.andersson@... >> <mailto:j.a.e.andersson@...>>: >> >> >> Hi! >> >> Thank you a lot for your feedback. >> >> I _am_ using the work of Josef et al but I decided that it was >> easier for me to copy/adapt the parts I need rather than going >> through the frustration of debugging and extended a code I don't >> fully understand. At the same time, there are some fundamental >> issues with their approach that I want to resolve. My interest in >> this is that we need a MATLAB interface to our software project (for >> which we already use SWIG). I want to make sure that this interface >> is going to be essentially as good as a handwritten interface. If >> this is not a possible outcome of my work, I'd rather just keep >> directing users to the Python interface. >> >> What is the fundamental problem with the single entry approach? The >> string identifier can of course be replaced by an integer index and >> the "ifelse ifelse if else" block be replaced by an C++ switch, >> which should compile to a lookup table. Is it then still >> inefficient? MATLAB MEX functions, which is the preferred way of >> interfacing C code, only have a single entry point. >> >> I'll update the names of "h" and "this" as suggested. >> >> The ownership of the C++ class is achieved by inheriting from the >> "handle" class. That turns the MATLAB class into a referencecounted >> object and copying is always by reference. The "delete" member >> function is MATLAB's way of declaring a destructor, called upon >> destruction. >> >> Inheritance relation will be added, the only issue is that I still >> need to figure out how to avoid multiple copies of the 'h' property >> in the case of multiple inheritance. >> >> Greetings and thanks! >> >> Joel >> >> >> On Apr 10, 2014 8:16 AM, "William S Fulton" <wsf@... >> <mailto:wsf@...>> wrote: >> >> On 08/04/14 20:34, Joel Andersson wrote: >> >> Hello! >> >> I did some work on a MATLAB module in my SWIG fork >> (https://github.com/__jaeandersson/swig/tree/matlab >> <https://github.com/jaeandersson/swig/tree/matlab>)__. I had >> look at Josef >> Pacula's work (https://github.com/twiho/__MatlabinSWIG >> <https://github.com/twiho/MatlabinSWIG>;) and the master >> >> theses of him and his colleage, but in the end I decided to >> start with a >> cleansheet design. Although I advocated using MATLAB's >> ability to call >> C shared libraries (via loadlibrary, calllib) earlier, in >> the end I >> think the safest and userfriendliest is to let all the >> calls for a SWIG >> module go through one MEXfunction. >> >> I uploaded some MATLAB interface code for the "class" >> example in SWIG. >> The code is incomplete, but the message should come across: >> https://gist.github.com/__jaeandersson/10169322/ >> >> <https://gist.github.com/jaeandersson/10169322/>; >> >> My plan was to let C/C++ pointers be stored in MATLAB by >> doing a >> reinterpret_cast to a 64bit unsigned int (uint64_t). This >> was suggested >> and has been tested in the following (nonSWIG) example on >> how to >> interface C++ with MATLAB: >> http://www.mathworks.com/__matlabcentral/fileexchange/__ >> 38964examplematlabclass__wrapperforac++class >> <http://www.mathworks.com/matlabcentral/fileexchange/ >> 38964examplematlabclasswrapperforac++class>. >> >> >> I would be happy to get some feedback on this draft. Also, >> if someone is >> interested in cooperating on this, please let me know. I am >> not sure if >> I have the time/resources to finish the module on my own. >> >> Hi Joel >> >> What are the essential problems for not using the previous work >> of Josef Pacula et al? It would be a shame to have another half >> finished module if you don't have the resources to finish this >> new one. >> >> Using a single entry method sounds rather inefficient for any >> reasonable sized module. Why not use multiple entry points like >> the other languages? They can be generated easily. >> >> The 'h' property is cryptic to say the least. I would mangle it >> and give it a sensible name. In Java it is called swigCPtr. >> Unless 'this' means something special in Matlab, call it 'self' >> as that is the naming used throughout SWIG. I don't see anything >> around ownership of the underlying C++ class pointers. I would >> take a look at the Java module  swigCMemOwn. I don't see any >> inheritance relationship between the Matlab Shape and Square >> classes, is that in the pipeline? >> >> William >> >> >> >> >>  >> >>  >> Joel Andersson >> Ptge. Busquets 1113, atico 3 >> E08940 Cornella de Llobregat, Spain >> Home: +34936034011 >> Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / >> +46707360512 (Sweden) >> > >   Joel Andersson Ptge. Busquets 1113, atico 3 E08940 Cornella de Llobregat, Spain Home: +34936034011 Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / +46707360512 (Sweden) 
From: William S Fulton <wsf@fu...>  20140415 19:35:29

> Anyway, I think I would prefer to focus on getting a complete working > wrapper for the "class" example and only then move on to more advanced > examples. I must say that the programming has been going quite smoothly. > Many things can be taken with little modifications from the Octave > module (Octave being essentially a MATLAB clone). I wouldn't exactly call that advanced... wrapping a simple function is about as basic as it gets! Basing it all on Octave makes sense, it is quite comprehensive in what it can do, so you'll get there in the end. William 
From: Joel Andersson <j.andersson@gm...>  20140414 11:50:33
Attachments:
Message as HTML

Hello William, all, Good news, I managed to get a (still incomplete) wrapper of the "class" example compiling and running from MATLAB! Including constructors, destructors and member functions. You will find the generated interface at https://gist.github.com/jaeandersson/10169322. Compiling and linking it can be done with the oneliner "mex example_wrap.cxx example.cxx" inside MATLAB. I don't think there should be any major problems to completing the rest of the "class" example. I had a look at "39.10.14 Prerequisites for adding a new language module to the SWIG distribution" and if I understand it right, it's enough to have the "class" and "simple" examples running, plus some documentation. I'll try to find time to do this in the coming weeks. Please let me know if there are some other requirements other than those listed. After that I'll have a look at the other unit tests. Regards, Joel 20140411 9:48 GMT+02:00 Joel Andersson <j.a.e.andersson@...>: > OK, I will have to look into that. I guess you would need to add a data > member indicating ownership to my SwigRef MATLAB class (the ABC holding the > pointer). Or do you have some other suggestion? In the public API of the > software I need a MATLAB interface for we work almost exclusively with > reference counted objects, no pointers. So I didn't give this much thought. > > Anyway, I think I would prefer to focus on getting a complete working > wrapper for the "class" example and only then move on to more advanced > examples. I must say that the programming has been going quite smoothly. > Many things can be taken with little modifications from the Octave module > (Octave being essentially a MATLAB clone). > > Regards, > Joel > > > > 20140410 21:24 GMT+02:00 William S Fulton <wsf@...>: > > It's not clear how the memory management will work. What will the wrappers >> look like for : >> >> %newobject SquareFactory; >> Square *SquareFactory() { return new Square(10); } >> >> Factory *Grab() { static Square local(20); return &local; } >> >> William >> >> >> On 10/04/14 10:44, Joel Andersson wrote: >> >>> For reference, I updated the code and added support for inheritance and >>> multiple inheritance (diamond problem avoided by adding a swigRef ABC): >>> https://gist.github.com/jaeandersson/10169322 >>> >>> Regards, >>> Joel >>> >>> >>> >>> 20140410 9:43 GMT+02:00 Joel Andersson <j.a.e.andersson@... >>> <mailto:j.a.e.andersson@...>>: >>> >>> >>> Hi! >>> >>> Thank you a lot for your feedback. >>> >>> I _am_ using the work of Josef et al but I decided that it was >>> easier for me to copy/adapt the parts I need rather than going >>> through the frustration of debugging and extended a code I don't >>> fully understand. At the same time, there are some fundamental >>> issues with their approach that I want to resolve. My interest in >>> this is that we need a MATLAB interface to our software project (for >>> which we already use SWIG). I want to make sure that this interface >>> is going to be essentially as good as a handwritten interface. If >>> this is not a possible outcome of my work, I'd rather just keep >>> directing users to the Python interface. >>> >>> What is the fundamental problem with the single entry approach? The >>> string identifier can of course be replaced by an integer index and >>> the "ifelse ifelse if else" block be replaced by an C++ switch, >>> which should compile to a lookup table. Is it then still >>> inefficient? MATLAB MEX functions, which is the preferred way of >>> interfacing C code, only have a single entry point. >>> >>> I'll update the names of "h" and "this" as suggested. >>> >>> The ownership of the C++ class is achieved by inheriting from the >>> "handle" class. That turns the MATLAB class into a referencecounted >>> object and copying is always by reference. The "delete" member >>> function is MATLAB's way of declaring a destructor, called upon >>> destruction. >>> >>> Inheritance relation will be added, the only issue is that I still >>> need to figure out how to avoid multiple copies of the 'h' property >>> in the case of multiple inheritance. >>> >>> Greetings and thanks! >>> >>> Joel >>> >>> >>> On Apr 10, 2014 8:16 AM, "William S Fulton" <wsf@... >>> <mailto:wsf@...>> wrote: >>> >>> On 08/04/14 20:34, Joel Andersson wrote: >>> >>> Hello! >>> >>> I did some work on a MATLAB module in my SWIG fork >>> (https://github.com/__jaeandersson/swig/tree/matlab >>> <https://github.com/jaeandersson/swig/tree/matlab>)__. I had >>> look at Josef >>> Pacula's work (https://github.com/twiho/__MatlabinSWIG >>> <https://github.com/twiho/MatlabinSWIG>;) and the master >>> >>> theses of him and his colleage, but in the end I decided to >>> start with a >>> cleansheet design. Although I advocated using MATLAB's >>> ability to call >>> C shared libraries (via loadlibrary, calllib) earlier, in >>> the end I >>> think the safest and userfriendliest is to let all the >>> calls for a SWIG >>> module go through one MEXfunction. >>> >>> I uploaded some MATLAB interface code for the "class" >>> example in SWIG. >>> The code is incomplete, but the message should come across: >>> https://gist.github.com/__jaeandersson/10169322/ >>> >>> <https://gist.github.com/jaeandersson/10169322/>; >>> >>> My plan was to let C/C++ pointers be stored in MATLAB by >>> doing a >>> reinterpret_cast to a 64bit unsigned int (uint64_t). This >>> was suggested >>> and has been tested in the following (nonSWIG) example on >>> how to >>> interface C++ with MATLAB: >>> http://www.mathworks.com/__matlabcentral/fileexchange/__ >>> 38964examplematlabclass__wrapperforac++class >>> <http://www.mathworks.com/matlabcentral/fileexchange/ >>> 38964examplematlabclasswrapperforac++class>. >>> >>> >>> I would be happy to get some feedback on this draft. Also, >>> if someone is >>> interested in cooperating on this, please let me know. I am >>> not sure if >>> I have the time/resources to finish the module on my own. >>> >>> Hi Joel >>> >>> What are the essential problems for not using the previous work >>> of Josef Pacula et al? It would be a shame to have another half >>> finished module if you don't have the resources to finish this >>> new one. >>> >>> Using a single entry method sounds rather inefficient for any >>> reasonable sized module. Why not use multiple entry points like >>> the other languages? They can be generated easily. >>> >>> The 'h' property is cryptic to say the least. I would mangle it >>> and give it a sensible name. In Java it is called swigCPtr. >>> Unless 'this' means something special in Matlab, call it 'self' >>> as that is the naming used throughout SWIG. I don't see anything >>> around ownership of the underlying C++ class pointers. I would >>> take a look at the Java module  swigCMemOwn. I don't see any >>> inheritance relationship between the Matlab Shape and Square >>> classes, is that in the pipeline? >>> >>> William >>> >>> >>> >>> >>>  >>> >>>  >>> Joel Andersson >>> Ptge. Busquets 1113, atico 3 >>> E08940 Cornella de Llobregat, Spain >>> Home: +34936034011 >>> Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / >>> +46707360512 (Sweden) >>> >> >> > > >  > >  > Joel Andersson > Ptge. Busquets 1113, atico 3 > E08940 Cornella de Llobregat, Spain > Home: +34936034011 > Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / +46707360512(Sweden) >   Joel Andersson Ptge. Busquets 1113, atico 3 E08940 Cornella de Llobregat, Spain Home: +34936034011 Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / +46707360512 (Sweden) 
From: William S Fulton <wsf@fu...>  20140415 19:34:58

Nowadays, I'll only accept new modules if the testsuite is also passing including some runtime tests converted from one of the other languages. Unfortunately we have too many half working languages which we are very hard to stop them from bitrotting as the tests don't work. SWIG is also fairly mature, so I want to keep the quality of the new language modules up with the level of maturity of the majority of SWIG. Sorry, if this means extra work to finish off some areas, but I think it is for the best. You can demonstrate the testsuite by setting up Travis testing by modifying the .travis.yml file in your Github branch. William On 14/04/14 12:50, Joel Andersson wrote: > Hello William, all, > > Good news, I managed to get a (still incomplete) wrapper of the "class" > example compiling and running from MATLAB! Including constructors, > destructors and member functions. You will find the generated interface > at https://gist.github.com/jaeandersson/10169322. > > Compiling and linking it can be done with the oneliner "mex > example_wrap.cxx example.cxx" inside MATLAB. > > I don't think there should be any major problems to completing the rest > of the "class" example. I had a look at "39.10.14 Prerequisites for > adding a new language module to the SWIG distribution" and if I > understand it right, it's enough to have the "class" and "simple" > examples running, plus some documentation. I'll try to find time to do > this in the coming weeks. Please let me know if there are some other > requirements other than those listed. > > After that I'll have a look at the other unit tests. > > Regards, > Joel > > > > > 20140411 9:48 GMT+02:00 Joel Andersson <j.a.e.andersson@... > <mailto:j.a.e.andersson@...>>: > > OK, I will have to look into that. I guess you would need to add a > data member indicating ownership to my SwigRef MATLAB class (the ABC > holding the pointer). Or do you have some other suggestion? In the > public API of the software I need a MATLAB interface for we work > almost exclusively with reference counted objects, no pointers. So I > didn't give this much thought. > > Anyway, I think I would prefer to focus on getting a complete > working wrapper for the "class" example and only then move on to > more advanced examples. I must say that the programming has been > going quite smoothly. Many things can be taken with little > modifications from the Octave module (Octave being essentially a > MATLAB clone). > > Regards, > Joel > > > > 20140410 21:24 GMT+02:00 William S Fulton <wsf@... > <mailto:wsf@...>>: > > It's not clear how the memory management will work. What will > the wrappers look like for : > > %newobject SquareFactory; > Square *SquareFactory() { return new Square(10); } > > Factory *Grab() { static Square local(20); return &local; } > > William > > > On 10/04/14 10:44, Joel Andersson wrote: > > For reference, I updated the code and added support for > inheritance and > multiple inheritance (diamond problem avoided by adding a > swigRef ABC): > https://gist.github.com/__jaeandersson/10169322 > <https://gist.github.com/jaeandersson/10169322>; > > Regards, > Joel > > > > 20140410 9:43 GMT+02:00 Joel Andersson > <j.a.e.andersson@... <mailto:j.a.e.andersson@...> > <mailto:j.a.e.andersson@... > <mailto:j.a.e.andersson@...>>>: > > > Hi! > > Thank you a lot for your feedback. > > I _am_ using the work of Josef et al but I decided that > it was > easier for me to copy/adapt the parts I need rather > than going > through the frustration of debugging and extended a > code I don't > fully understand. At the same time, there are some > fundamental > issues with their approach that I want to resolve. My > interest in > this is that we need a MATLAB interface to our software > project (for > which we already use SWIG). I want to make sure that > this interface > is going to be essentially as good as a handwritten > interface. If > this is not a possible outcome of my work, I'd rather > just keep > directing users to the Python interface. > > What is the fundamental problem with the single entry > approach? The > string identifier can of course be replaced by an > integer index and > the "ifelse ifelse if else" block be replaced by an > C++ switch, > which should compile to a lookup table. Is it then still > inefficient? MATLAB MEX functions, which is the > preferred way of > interfacing C code, only have a single entry point. > > I'll update the names of "h" and "this" as suggested. > > The ownership of the C++ class is achieved by > inheriting from the > "handle" class. That turns the MATLAB class into a > referencecounted > object and copying is always by reference. The "delete" > member > function is MATLAB's way of declaring a destructor, > called upon > destruction. > > Inheritance relation will be added, the only issue is > that I still > need to figure out how to avoid multiple copies of the > 'h' property > in the case of multiple inheritance. > > Greetings and thanks! > > Joel > > > On Apr 10, 2014 8:16 AM, "William S Fulton" > <wsf@... <mailto:wsf@...> > <mailto:wsf@... > <mailto:wsf@...>>> wrote: > > On 08/04/14 20:34, Joel Andersson wrote: > > Hello! > > I did some work on a MATLAB module in my SWIG fork > > (https://github.com/____jaeandersson/swig/tree/matlab > <https://github.com/__jaeandersson/swig/tree/matlab>; > > <https://github.com/__jaeandersson/swig/tree/matlab > <https://github.com/jaeandersson/swig/tree/matlab>>__)__. I had > look at Josef > Pacula's work > (https://github.com/twiho/____MatlabinSWIG > <https://github.com/twiho/__MatlabinSWIG>; > <https://github.com/twiho/__MatlabinSWIG > <https://github.com/twiho/MatlabinSWIG>>;) and the master > > theses of him and his colleage, but in the end > I decided to > start with a > cleansheet design. Although I advocated using > MATLAB's > ability to call > C shared libraries (via loadlibrary, calllib) > earlier, in > the end I > think the safest and userfriendliest is to let > all the > calls for a SWIG > module go through one MEXfunction. > > I uploaded some MATLAB interface code for the > "class" > example in SWIG. > The code is incomplete, but the message should > come across: > https://gist.github.com/____jaeandersson/10169322/ > <https://gist.github.com/__jaeandersson/10169322/>; > > > <https://gist.github.com/__jaeandersson/10169322/ > <https://gist.github.com/jaeandersson/10169322/>>; > > My plan was to let C/C++ pointers be stored in > MATLAB by doing a > reinterpret_cast to a 64bit unsigned int > (uint64_t). This > was suggested > and has been tested in the following (nonSWIG) > example on > how to > interface C++ with MATLAB: > http://www.mathworks.com/____matlabcentral/fileexchange/____38964examplematlabclass____wrapperforac++class > <http://www.mathworks.com/__matlabcentral/fileexchange/__38964examplematlabclass__wrapperforac++class>; > > <http://www.mathworks.com/__matlabcentral/fileexchange/__38964examplematlabclass__wrapperforac++class > <http://www.mathworks.com/matlabcentral/fileexchange/38964examplematlabclasswrapperforac++class>>;. > > > I would be happy to get some feedback on this > draft. Also, > if someone is > interested in cooperating on this, please let > me know. I am > not sure if > I have the time/resources to finish the module > on my own. > > Hi Joel > > What are the essential problems for not using the > previous work > of Josef Pacula et al? It would be a shame to have > another half > finished module if you don't have the resources to > finish this > new one. > > Using a single entry method sounds rather > inefficient for any > reasonable sized module. Why not use multiple entry > points like > the other languages? They can be generated easily. > > The 'h' property is cryptic to say the least. I > would mangle it > and give it a sensible name. In Java it is called > swigCPtr. > Unless 'this' means something special in Matlab, > call it 'self' > as that is the naming used throughout SWIG. I don't > see anything > around ownership of the underlying C++ class > pointers. I would > take a look at the Java module  swigCMemOwn. I > don't see any > inheritance relationship between the Matlab Shape > and Square > classes, is that in the pipeline? > > William > > > > >  > >  > Joel Andersson > Ptge. Busquets 1113, atico 3 > E08940 Cornella de Llobregat, Spain > Home: +34936034011 <tel:%2B34936034011> > Mobile: +32486672874 <tel:%2B32486672874> (Belgium) / > +34634408800 <tel:%2B34634408800> (Spain) / > +46707360512 <tel:%2B46707360512> (Sweden) > > > > > >  > >  > Joel Andersson > Ptge. Busquets 1113, atico 3 > E08940 Cornella de Llobregat, Spain > Home: +34936034011 <tel:%2B34936034011> > Mobile: +32486672874 <tel:%2B32486672874> (Belgium) / > +34634408800 <tel:%2B34634408800> (Spain) / +46707360512 > <tel:%2B46707360512> (Sweden) > > > > >  > >  > Joel Andersson > Ptge. Busquets 1113, atico 3 > E08940 Cornella de Llobregat, Spain > Home: +34936034011 > Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / > +46707360512 (Sweden) 
From: Joel Andersson <j.andersson@gm...>  20140415 22:00:09
Attachments:
Message as HTML

OK, no problem. We need essentially all SWIG features anyway to be able to wrap our C++ project, so it doesn't hurt addressing right away. I've never managed to get the test suite running on the Mac that I'm developing on, but I guess I could find a Linux machine. Thanks for your help! Joel 20140415 21:34 GMT+02:00 William S Fulton <wsf@...>: > Nowadays, I'll only accept new modules if the testsuite is also passing > including some runtime tests converted from one of the other languages. > Unfortunately we have too many half working languages which we are very > hard to stop them from bitrotting as the tests don't work. SWIG is also > fairly mature, so I want to keep the quality of the new language modules up > with the level of maturity of the majority of SWIG. Sorry, if this means > extra work to finish off some areas, but I think it is for the best. You > can demonstrate the testsuite by setting up Travis testing by modifying > the .travis.yml file in your Github branch. > > William > > > On 14/04/14 12:50, Joel Andersson wrote: > >> Hello William, all, >> >> Good news, I managed to get a (still incomplete) wrapper of the "class" >> example compiling and running from MATLAB! Including constructors, >> destructors and member functions. You will find the generated interface >> at https://gist.github.com/jaeandersson/10169322. >> >> Compiling and linking it can be done with the oneliner "mex >> example_wrap.cxx example.cxx" inside MATLAB. >> >> I don't think there should be any major problems to completing the rest >> of the "class" example. I had a look at "39.10.14 Prerequisites for >> adding a new language module to the SWIG distribution" and if I >> understand it right, it's enough to have the "class" and "simple" >> examples running, plus some documentation. I'll try to find time to do >> this in the coming weeks. Please let me know if there are some other >> requirements other than those listed. >> >> After that I'll have a look at the other unit tests. >> >> Regards, >> Joel >> >> >> >> >> 20140411 9:48 GMT+02:00 Joel Andersson <j.a.e.andersson@... >> <mailto:j.a.e.andersson@...>>: >> >> >> OK, I will have to look into that. I guess you would need to add a >> data member indicating ownership to my SwigRef MATLAB class (the ABC >> holding the pointer). Or do you have some other suggestion? In the >> public API of the software I need a MATLAB interface for we work >> almost exclusively with reference counted objects, no pointers. So I >> didn't give this much thought. >> >> Anyway, I think I would prefer to focus on getting a complete >> working wrapper for the "class" example and only then move on to >> more advanced examples. I must say that the programming has been >> going quite smoothly. Many things can be taken with little >> modifications from the Octave module (Octave being essentially a >> MATLAB clone). >> >> Regards, >> Joel >> >> >> >> 20140410 21:24 GMT+02:00 William S Fulton <wsf@... >> <mailto:wsf@...>>: >> >> >> It's not clear how the memory management will work. What will >> the wrappers look like for : >> >> %newobject SquareFactory; >> Square *SquareFactory() { return new Square(10); } >> >> Factory *Grab() { static Square local(20); return &local; } >> >> William >> >> >> On 10/04/14 10:44, Joel Andersson wrote: >> >> For reference, I updated the code and added support for >> inheritance and >> multiple inheritance (diamond problem avoided by adding a >> swigRef ABC): >> https://gist.github.com/__jaeandersson/10169322 >> >> <https://gist.github.com/jaeandersson/10169322>; >> >> Regards, >> Joel >> >> >> >> 20140410 9:43 GMT+02:00 Joel Andersson >> <j.a.e.andersson@... <mailto:j.a.e.andersson@...> >> <mailto:j.a.e.andersson@... >> >> <mailto:j.a.e.andersson@...>>>: >> >> >> Hi! >> >> Thank you a lot for your feedback. >> >> I _am_ using the work of Josef et al but I decided that >> it was >> easier for me to copy/adapt the parts I need rather >> than going >> through the frustration of debugging and extended a >> code I don't >> fully understand. At the same time, there are some >> fundamental >> issues with their approach that I want to resolve. My >> interest in >> this is that we need a MATLAB interface to our software >> project (for >> which we already use SWIG). I want to make sure that >> this interface >> is going to be essentially as good as a handwritten >> interface. If >> this is not a possible outcome of my work, I'd rather >> just keep >> directing users to the Python interface. >> >> What is the fundamental problem with the single entry >> approach? The >> string identifier can of course be replaced by an >> integer index and >> the "ifelse ifelse if else" block be replaced by an >> C++ switch, >> which should compile to a lookup table. Is it then still >> inefficient? MATLAB MEX functions, which is the >> preferred way of >> interfacing C code, only have a single entry point. >> >> I'll update the names of "h" and "this" as suggested. >> >> The ownership of the C++ class is achieved by >> inheriting from the >> "handle" class. That turns the MATLAB class into a >> referencecounted >> object and copying is always by reference. The "delete" >> member >> function is MATLAB's way of declaring a destructor, >> called upon >> destruction. >> >> Inheritance relation will be added, the only issue is >> that I still >> need to figure out how to avoid multiple copies of the >> 'h' property >> in the case of multiple inheritance. >> >> Greetings and thanks! >> >> Joel >> >> >> On Apr 10, 2014 8:16 AM, "William S Fulton" >> <wsf@... <mailto:wsf@...> >> <mailto:wsf@... >> >> <mailto:wsf@...>>> wrote: >> >> On 08/04/14 20:34, Joel Andersson wrote: >> >> Hello! >> >> I did some work on a MATLAB module in my SWIG >> fork >> >> (https://github.com/____jaeandersson/swig/tree/matlab >> <https://github.com/__jaeandersson/swig/tree/matlab>; >> >> <https://github.com/__jaeandersson/swig/tree/matlab >> <https://github.com/jaeandersson/swig/tree/matlab>>__)__. I >> had >> >> look at Josef >> Pacula's work >> (https://github.com/twiho/____MatlabinSWIG >> <https://github.com/twiho/__MatlabinSWIG>; >> >> <https://github.com/twiho/__MatlabinSWIG >> <https://github.com/twiho/MatlabinSWIG>>;) and the master >> >> theses of him and his colleage, but in the end >> I decided to >> start with a >> cleansheet design. Although I advocated using >> MATLAB's >> ability to call >> C shared libraries (via loadlibrary, calllib) >> earlier, in >> the end I >> think the safest and userfriendliest is to let >> all the >> calls for a SWIG >> module go through one MEXfunction. >> >> I uploaded some MATLAB interface code for the >> "class" >> example in SWIG. >> The code is incomplete, but the message should >> come across: >> https://gist.github.com/____jaeandersson/10169322/ >> <https://gist.github.com/__jaeandersson/10169322/>; >> >> >> >> <https://gist.github.com/__jaeandersson/10169322/ >> <https://gist.github.com/jaeandersson/10169322/>>; >> >> My plan was to let C/C++ pointers be stored in >> MATLAB by doing a >> reinterpret_cast to a 64bit unsigned int >> (uint64_t). This >> was suggested >> and has been tested in the following (nonSWIG) >> example on >> how to >> interface C++ with MATLAB: >> http://www.mathworks.com/____matlabcentral/fileexchange/___ >> _38964examplematlabclass____wrapperforac++class >> <http://www.mathworks.com/__matlabcentral/fileexchange/__ >> 38964examplematlabclass__wrapperforac++class> >> >> >> <http://www.mathworks.com/__matlabcentral/fileexchange/__ >> 38964examplematlabclass__wrapperforac++class >> <http://www.mathworks.com/matlabcentral/fileexchange/ >> 38964examplematlabclasswrapperforac++class>>. >> >> >> I would be happy to get some feedback on this >> draft. Also, >> if someone is >> interested in cooperating on this, please let >> me know. I am >> not sure if >> I have the time/resources to finish the module >> on my own. >> >> Hi Joel >> >> What are the essential problems for not using the >> previous work >> of Josef Pacula et al? It would be a shame to have >> another half >> finished module if you don't have the resources to >> finish this >> new one. >> >> Using a single entry method sounds rather >> inefficient for any >> reasonable sized module. Why not use multiple entry >> points like >> the other languages? They can be generated easily. >> >> The 'h' property is cryptic to say the least. I >> would mangle it >> and give it a sensible name. In Java it is called >> swigCPtr. >> Unless 'this' means something special in Matlab, >> call it 'self' >> as that is the naming used throughout SWIG. I don't >> see anything >> around ownership of the underlying C++ class >> pointers. I would >> take a look at the Java module  swigCMemOwn. I >> don't see any >> inheritance relationship between the Matlab Shape >> and Square >> classes, is that in the pipeline? >> >> William >> >> >> >> >>  >> >>  >> Joel Andersson >> Ptge. Busquets 1113, atico 3 >> E08940 Cornella de Llobregat, Spain >> Home: +34936034011 <tel:%2B34936034011> >> Mobile: +32486672874 <tel:%2B32486672874> (Belgium) / >> +34634408800 <tel:%2B34634408800> (Spain) / >> +46707360512 <tel:%2B46707360512> (Sweden) >> >> >> >> >> >> >>  >> >>  >> Joel Andersson >> Ptge. Busquets 1113, atico 3 >> E08940 Cornella de Llobregat, Spain >> Home: +34936034011 <tel:%2B34936034011> >> Mobile: +32486672874 <tel:%2B32486672874> (Belgium) / >> +34634408800 <tel:%2B34634408800> (Spain) / +46707360512 >> <tel:%2B46707360512> (Sweden) >> >> >> >> >> >>  >> >>  >> Joel Andersson >> Ptge. Busquets 1113, atico 3 >> E08940 Cornella de Llobregat, Spain >> Home: +34936034011 >> Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / >> +46707360512 (Sweden) >> > >   Joel Andersson Ptge. Busquets 1113, atico 3 E08940 Cornella de Llobregat, Spain Home: +34936034011 Mobile: +32486672874 (Belgium) / +34634408800 (Spain) / +46707360512 (Sweden) 