RenameField - Rename a fields of a struct
T = RenameField(S, Old, New)
S: Struct or struct array.
Old: String or cell string, name of the field to be renamed.
New: String or cell string, new field name, which must be a valid Matlab symbol.
T: Struct S with renamed fields.
S.A = 1; S.B = 2;
T = RenameField(S, 'B', 'C'); % >> T.A = 1, T.C = 2
This function was created after a discussion in Loren's blog:
Tested: Matlab 6.5/2009a, WinXP 32 bit, LCC2.4/3.8, BCC5.5, OpemWatcom 1.8, MSVC 2008
Compatibility to 64 bit, Linux, MacOS is assumed.
Look in the C-file for instructions to compile the Mex file at first.
A slower M-version is included, but disabled by a call to ERROR. The M-version does not check the validity of the new names.
@James: Thanks for this interesting suggestion. Unfortunately, since Matlab 2014a mxCreateReference is not supported anymore. I've tried it with the replacement <http://www.mathworks.com/matlabcentral/answers/231824-issue-with-mex-function#comment_302416>. It works reliably, but to my surprise it is some percent slower: 1e6 calls, SharedDataCopy: 15.58 s, Reference: 15.98 s (measured with for-loop&tic/toc, equivalent result for timeit).
During the tests I found, that the mexw64 compiled with R2009a/WinSDK7.0 is 10% faster than with R2016b/WinSDK7.1, both measured in R2016b and with the SharedDataCopy method.
And when I run the same mexw64 in R2009a, it takes 11.5 s only, 25% faster! Sigh. Experiments with undocumented mex functions would be more challenging, if using ancient Matlab versions is not more efficient.
You might consider using mxCreateReference instead of mxCreateSharedDataCopy. It has the same signature. This will directly create the reference copy needed for the new struct (like what would happen at the m-file level). Using mxCreateSharedDataCopy causes mxArray headers to be created ... which are then immediately destroyed anyway by the mxSetFieldByNumber call as it creates a reference copy in the background. So the mxArray header stuff that mxCreateSharedDataCopy creates is just wasted effort. Using mxCreateReference may give you a slight boost in execution speed because of this.
@Renan: I cannot find an intuitive input syntax for considering subfields. E.g. using nested cells would increase the complexity of the function and of the caller, such that bugs becomes more likely.
It would be nicer and simpler to create an M-function, which calls RenameField recursively.
Very nice work! Exactly what I was looking for.
One suggestion: Could you change your script such that it renames all the subfields (fields within fields, e.g., S.field1.field2) in a structure?
@Matthew: Thanks for the rating. Do you have a suggestion for any improvements?
@Michael: Thanks for the comments. In the comment section of the C-file you find instruction for considering the C99 style comments with GCC under Linux. The C99 standard is 12 years old and the default for MSVC, LCC, OpenWatcom, BCC and ICC. I don't know, why the -std=c99 flag is not included as default in Matlab's Mex-options file of the GCC, but it is much better to write an improvement request to TMW, than to want FEX submissions to be formatted according to a 22 year old standard. BTW: You can rename the file to .cpp also.
The cell string input is a nice idea and I'll insert it soon.
This function is exactly what I was looking for, since it preserves the original ordering! Great!
Even though I did not manage to compile the mex file due to the c++ comment style...
The function would be even better, if it would take also cell arrays for the old and new fieldnames.
Accept cell strings as input.
Download apps, toolboxes, and other File Exchange content using Add-On Explorer in MATLAB.