API changes in R2019a?
Mostrar comentarios más antiguos
I have a (Win64) C# software package allowing users to transfer data to MATLAB for user defined processing through a MATLAB script and transfer back the results.
It relies on the MATLAB API with libeng.dll etc, and was working fine with R2018b, but has stopped working with R2019a. I changed nothing, so assume something changed with the MATLAB API, but can find no mention of such a change here or on the 'News' pages.
Any bright ideas?
1 comentario
James Tursa
el 30 de Jul. de 2019
Did you recompile it with R2019a, or are you using the previously compiled code?
Respuestas (1)
James Tursa
el 30 de Jul. de 2019
0 votos
I don't know if this is the cause of your problems, but there was a change to the low level mxArray variable structure in R2019a. So code might have to be recompiled in order to work.
5 comentarios
Bo
el 31 de Jul. de 2019
Bruno Luong
el 31 de Jul. de 2019
James, what is the low-level change of mxArray? I did not notice and my old mex files are still working without recompile them.
James Tursa
el 31 de Jul. de 2019
Editada: James Tursa
el 31 de Jul. de 2019
Documented in my mex MATLAB API version FEX submission here (in the header file):
And here is the low level change for R2019a:
* R2019a - First version where the CrossLink field in the mxArray header
* has been moved next to the reverse CrossLink field. I.e.,
* R2018b-:
* mxArray *RevCrossLink;
* mxClassID ClassID;
* int VariableType;
* mxArray *CrossLink;
* :
* etc.
* R2019a+:
* mxArray *RevCrossLink;
* mxArray *CrossLink;
* mxClassID ClassID;
* int VariableType;
* :
* etc.
If you are only calling API functions that deal with this in the background then I can easily see that this may not affect your mex routines.
Bruno Luong
el 31 de Jul. de 2019
OK so they change the order of the fields. I can't see the motivation. The aligment is more or less identical for 64-bit pointer (all MATLAB) no?
That looks odd.
James Tursa
el 31 de Jul. de 2019
Since ClassID and VariableType are both ints they occupy 4 bytes each. Having them next to each other means they won't mess up any 8-byte boundary alignments for the stuff around them. So, yes, I agree that the compiler won't need to add any padding in either the old or the new definitions to maintain 8-byte boundary alignments of the nearby fields.
Motivation for the change? I suppose the new definition looks nicer having the crosslink stuff next to each other. But I suspect the real motivation is just to irritate me and mess up my mex hacking code ...
Categorías
Más información sobre C Matrix API en Centro de ayuda y File Exchange.
Productos
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!