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 "if-else if-else 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 reference-counted 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!
On Apr 10, 2014 8:16 AM, "William S Fulton" <firstname.lastname@example.org> wrote:
On 08/04/14 20:34, Joel Andersson wrote:
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/Matlab-in-SWIG) and the master
theses of him and his colleage, but in the end I decided to start with a
clean-sheet 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 user-friendliest is to let all the calls for a SWIG
module go through one MEX-function.
I uploaded some MATLAB interface code for the "class" example in SWIG.
The code is incomplete, but the message should come across:
My plan was to let C/C++ pointers be stored in MATLAB by doing a
reinterpret_cast to a 64-bit unsigned int (uint64_t). This was suggested
and has been tested in the following (non-SWIG) example on how to
interface C++ with MATLAB:
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.
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?