When The Mathworks® introduced MATLAB® version R2008a they included a new object oriented format called classdef. This addition greatly expanded the object oriented capabilities of MATLAB® at the m-file level. There were also two new mex API functions introduced at that same time: mxGetProperty and mxSetProperty. Unfortunately, both of these functions work with copies of the properties and not the actual properties themselves. So whereas the old-style class variables can easily and efficiently be accessed with the mex API functions mxGetField, mxGetFieldByNumber, mxSetField, and mxSetFieldByNumber since they use pointers to the original properties, there were no equivalent mex API functions provided for the newer classdef classes. This presents a problem for the mex programmer, particularly if the properties in question are large. Using mxGetProperty will significantly slow the routine down and also risk using up valuable heap memory. The same is true for mxSetProperty.
The new mxGetPropertyPtr C-mex function provided in this package solves half of the problem. It returns a pointer to the original property rather than a pointer to a copy of the property. Thus the property can be accessed efficiently inside a mex routine. The other half of the problem is solved by the new mxSetPropertySDC function, which sets a property to a shared data copy of an mxArray.
These functions have been tested on various Win32 and Win64 versions of MATLAB R2009a - R2019a. For R2018a and later you are expected to use the -R2018a option when compiling your mex code with this submission.
James Tursa (2019). mxGetPropertyPtr & mxSetPropertySDC C-mex functions (https://www.mathworks.com/matlabcentral/fileexchange/30672-mxgetpropertyptr-mxsetpropertysdc-c-mex-functions), MATLAB Central File Exchange. Retrieved .
There may be a missing file, matlab_version.c. Until I fix this, you can download this file from my "C Mex MATLAB Version" submission.
This does not seem to work in R2016b, 64-bit, in Windows 7. In particular, calling it multiple times in a row for the same property, not doing anything else in between, yields different answers each time:
>> thing = Thing(42)
Thing with properties:
I'd really like to have a standalone C (or C++) function that I could call from within my own mex function. My interest is in modifying the property without making the copy from within the mex file (actually, I'd like to modify a property of a property of a property ... ).
I think I could strip out what I need from GetPropertyPtrx.c but does anyone know if this code is still good for 2013a? I guess I could simple try the test function. It is utterly amazing to me that TMW does not support this function natively from within their mx library of functions. Without it, the usefulness of working with handle objects from within mex functions is completely negated.
Works great for Windows. Is there a solution for LINUX as well?
Excellent and very interesting on the way MATLAB handles transmission of handles. I have found the auto-test difficult to use since the "memory" function of matlab does not exist on linux and the testing done in this submission is done within a mex file.
Updated for R2019a
Updated the doc for 4.00 and R2018a
Updated code for R2018a. (The doc will be updated soon to reflect this)
mxSetPropertySDC now available.
Updated for later versions of MATLAB (which have a different mex input argument passing convention) and tested for various 64-bit versions.
Create scripts with code, output, and formatted text in a single executable document.