From: Kris Thielemans <kris.thielemans@gm...>  20140615 08:18:17

Hi Joel I found the problem why swigged functions were still returning SwigRef objects as opposed to objects of proper type. I had forgotten to add the package name to the stored string (in clientdata)... For instance, when you had a package foo with class Bar, Swig_MATLAB_NewPointerObj was trying to create a "Bar" object as opposed to a "foo.Bar" object, which was clearly incorrect. This seems to mean that we now only return SwigRef objects if they are not part of the package, e.g. any objects of a nonwrapped class. This seems unavoidable however. Another example, if you wrap a function const float& a(); Swig_MATLAB_NewPointerObj will attempt to create an object of type p_float, which matlab doesn't know what to do with, so we will fall back to a SwigRef. This example looks a bit artificial, but I get it because I am using templates ("template <class T> const T& a()") which I then instantiate with T=float. In C++, that's fine, but in MATLAB, we now end up with a largely unusable value. This is the same for other languages though (I think). For now, I've let Swig_MATLAB_NewPointerObj issue matlab warnings when this kind of thing is happening. (the user can then switch them off in matlab). I've pushed the changes to https://github.com/KrisThielemans/swig. Kris PS: your merge with swig/master and the new "casebased" dispatching in the gateway just work for me. great! PPS: I still get the fake "destructorclass" problem (now for some other classes). I'll try to investigate this a bit. 