[Swig-devel] [MATLAB] swig_this necessary?

[Kris Thielemans]

Dear all

I've been trying to kill a few more errors when running the test-suite for
Matlab. One example that fails is voidtest. The reason for that is that
voidtest_runme.m (an almost-copy of the Octave version) uses the swig_this
function, which we currently don't have.

Looking at the Octave implementation, it says that swig_this "returns the
underlying C/C++ pointer of a SWIG-wrapped object". When checking
voidtest_runme.py, it corresponds to "object.this" in Python.

Now we (i.e. Joel!) can probably make such a function for the Matlab
version, but I don't understand why someone would need to have access to
this. It looks quite unsafe to me.

Can anyone clarify this?

Thanks
Kris



------------------------------------------------------------------------------

[William S Fulton]

Post by Kris Thielemans
Dear all
I've been trying to kill a few more errors when running the test-suite for
Matlab. One example that fails is voidtest. The reason for that is that
voidtest_runme.m (an almost-copy of the Octave version) uses the swig_this
function, which we currently don't have.
Looking at the Octave implementation, it says that swig_this "returns the
underlying C/C++ pointer of a SWIG-wrapped object". When checking
voidtest_runme.py, it corresponds to "object.this" in Python.
Now we (i.e. Joel!) can probably make such a function for the Matlab
version, but I don't understand why someone would need to have access to
this. It looks quite unsafe to me.
Can anyone clarify this?

The statically typed languages (Java, C#...) don't provide access to
the underlying C pointer by default, but it is possible for a user to
get access to it via typemaps that modify the wrapped proxy class.
Python makes it available by default. I'm not entirely sure what the
other languages do. I don't think it is terribly important what you
decide.

Access to the underlying pointer could be useful for various reasons
such identifying the underlying pointer/object. I doubt this is needed
very much though. It could certainly be unsafe to modify, but not
necessarily for read only access. SWIG doesn't attempt to stop users
doing anything dangerous though, see
http://swig.org/Doc3.0/Introduction.html#Introduction_nn13.

William

------------------------------------------------------------------------------

[Kris Thielemans]

From: William S Fulton,Sent: 29 August 2015 13:19

Post by William S Fulton

Post by Kris Thielemans
Dear all
I've been trying to kill a few more errors when running the test-suite for
Matlab. One example that fails is voidtest. The reason for that is that
voidtest_runme.m (an almost-copy of the Octave version) uses the swig_this
function, which we currently don't have.
Looking at the Octave implementation, it says that swig_this "returns the
underlying C/C++ pointer of a SWIG-wrapped object". When checking
voidtest_runme.py, it corresponds to "object.this" in Python.
Now we (i.e. Joel!) can probably make such a function for the Matlab
version, but I don't understand why someone would need to have access to
this. It looks quite unsafe to me.

The statically typed languages (Java, C#...) don't provide access to
the underlying C pointer by default, but it is possible for a user to
get access to it via typemaps that modify the wrapped proxy class.
Python makes it available by default. I'm not entirely sure what the
other languages do. I don't think it is terribly important what you
decide.
Access to the underlying pointer could be useful for various reasons
such identifying the underlying pointer/object. I doubt this is needed
very much though. It could certainly be unsafe to modify, but not
necessarily for read only access.

Thanks William. As nobody has asked for this for MATLAB, and it might be unsafe, and I wouldn't know where to start, I vote for documenting that we don't provide this facility yet for MATLAB, and just remove the corresponding tests from the runme.m files that use swig_this. That'd allow us to get through our test-suite more quickly.

Joel&William, is this ok for you?

Kris


------------------------------------------------------------------------------

[William S Fulton]

Post by Kris Thielemans
From: William S Fulton,Sent: 29 August 2015 13:19

Post by William S Fulton

Post by Kris Thielemans
Dear all
I've been trying to kill a few more errors when running the test-suite

for

Post by William S Fulton

Post by Kris Thielemans
Matlab. One example that fails is voidtest. The reason for that is that
voidtest_runme.m (an almost-copy of the Octave version) uses the

swig_this

Post by William S Fulton

Post by Kris Thielemans
function, which we currently don't have.
Looking at the Octave implementation, it says that swig_this "returns

the

Post by William S Fulton

Post by Kris Thielemans
underlying C/C++ pointer of a SWIG-wrapped object". When checking
voidtest_runme.py, it corresponds to "object.this" in Python.
Now we (i.e. Joel!) can probably make such a function for the Matlab
version, but I don't understand why someone would need to have access

to

Post by William S Fulton

Post by Kris Thielemans
this. It looks quite unsafe to me.

The statically typed languages (Java, C#...) don't provide access to
the underlying C pointer by default, but it is possible for a user to
get access to it via typemaps that modify the wrapped proxy class.
Python makes it available by default. I'm not entirely sure what the
other languages do. I don't think it is terribly important what you
decide.
Access to the underlying pointer could be useful for various reasons
such identifying the underlying pointer/object. I doubt this is needed
very much though. It could certainly be unsafe to modify, but not
necessarily for read only access.

Thanks William. As nobody has asked for this for MATLAB, and it might be
unsafe, and I wouldn't know where to start, I vote for documenting that we
don't provide this facility yet for MATLAB, and just remove the
corresponding tests from the runme.m files that use swig_this. That'd allow
us to get through our test-suite more quickly.
Joel&William, is this ok for you?

Sure fine with me.

William

[Joel Andersson]

Hello,

I'm ok with whatever solution as this isn't really a feature I plan to use.

But it's not too hard to implement this if you really want. After the last
iteration, the "swigPtr" proxy class property is a pointer to an internal
SwigPtr structure, cast to an unsigned 64-bit integer type (uint64 in
MATLAB). Since the first field of the SwigPtr is the raw pointer, all you
want to do is to dereference the "swigPtr" property and cast it to a type
MATLAB supports (e.g. uint64).

Would require one more mex file being added though, as this is common to
all modules.

Joel

Post by Kris Thielemans
From: William S Fulton,Sent: 29 August 2015 13:19

Post by William S Fulton

Post by Kris Thielemans
Dear all
I've been trying to kill a few more errors when running the test-suite

for

Post by William S Fulton

Post by Kris Thielemans
Matlab. One example that fails is voidtest. The reason for that is that
voidtest_runme.m (an almost-copy of the Octave version) uses the

swig_this

Post by William S Fulton

Post by Kris Thielemans
function, which we currently don't have.
Looking at the Octave implementation, it says that swig_this "returns

the

Post by William S Fulton

Post by Kris Thielemans
underlying C/C++ pointer of a SWIG-wrapped object". When checking
voidtest_runme.py, it corresponds to "object.this" in Python.
Now we (i.e. Joel!) can probably make such a function for the Matlab
version, but I don't understand why someone would need to have access

to

Post by William S Fulton

Post by Kris Thielemans
this. It looks quite unsafe to me.

The statically typed languages (Java, C#...) don't provide access to
the underlying C pointer by default, but it is possible for a user to
get access to it via typemaps that modify the wrapped proxy class.
Python makes it available by default. I'm not entirely sure what the
other languages do. I don't think it is terribly important what you
decide.
Access to the underlying pointer could be useful for various reasons
such identifying the underlying pointer/object. I doubt this is needed
very much though. It could certainly be unsafe to modify, but not
necessarily for read only access.

Thanks William. As nobody has asked for this for MATLAB, and it might be
unsafe, and I wouldn't know where to start, I vote for documenting that we
don't provide this facility yet for MATLAB, and just remove the
corresponding tests from the runme.m files that use swig_this. That'd allow
us to get through our test-suite more quickly.
Joel&William, is this ok for you?
Kris
------------------------------------------------------------------------------
_______________________________________________
Swig-devel mailing list
https://lists.sourceforge.net/lists/listinfo/swig-devel