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



2014-04-10 21:24 GMT+02:00 William S Fulton <wsf@fultondesigns.co.uk>:
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



2014-04-10 9:43 GMT+02:00 Joel Andersson <j.a.e.andersson@gmail.com
<mailto:j.a.e.andersson@gmail.com>>:


    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 "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!

    Joel


    On Apr 10, 2014 8:16 AM, "William S Fulton" <wsf@fultondesigns.co.uk
    <mailto:wsf@fultondesigns.co.uk>> 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/__Matlab-in-SWIG
            <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:
            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 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:
            http://www.mathworks.com/__matlabcentral/fileexchange/__38964-example-matlab-class-__wrapper-for-a-c++-class
            <http://www.mathworks.com/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-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 11-13, atico 3
E-08940 Cornella de Llobregat, Spain
Home: +34-93-6034011
Mobile: +32-486-672874 (Belgium) / +34-63-4408800 (Spain) /
+46-707-360512 (Sweden)




--

--
Joel Andersson
Ptge. Busquets 11-13, atico 3
E-08940 Cornella de Llobregat, Spain
Home: +34-93-6034011
Mobile: +32-486-672874 (Belgium) / +34-63-4408800 (Spain) / +46-707-360512 (Sweden)