@Alex – thanks, but keep in mind that new functions will only work on the recent Matlab releases. If your code needs to work on older Matlab releases, you could revert to the previous “hold-your-nose” undocumented functionality. This can easily be achieved using a simple try-catch block:

try
    % use documented functions that only run on very recent Matlab releases
    ...
catch
    % use undocumented functions that work on older Matlab releases
    ...
end

I was looking up how to do this exact task today. I was about to hold my nose and use the internal controllib function, when I happened to chance across a slightly newer MathWorks function, convertContainedStringsToChars: https://www.mathworks.com/help/matlab/ref/convertcontainedstringstochars.html

That function recurses in just the way I want it to, and it meets several of your other benefits: it works recursively inside cell arrays and struct fields, and it works with ans without needing an output variable. It does still turn "" into a 0x0 empty char array, but that’s fine for my use case.

@Henry – read my response to Sam’s comment above, where I explain the benefits of controllib.internal.util.hString2Char over convertStringsToChars.

Regarding the difference between "string" and 'char', which did annoy me sometimes. Until recent days, I found that Matlab itself solved this issue by providing the convertStringsToChars and convertContainedStringsToChars functions. This page tells the details: Update Your Code to Accept Strings

It helps me, so I ‘d like to share it with you. Hope it will interest you.

2) Since I have problem with tcpip command (thread/ async pbwith big data stream to transfert over tcp) I look at the source code fo tcpip command. And I discover this command :
instrument.internal.stringConversionHelpers.str2char

Ok, it is in Instrument Toolbox, but if you have it, it seems best (more clear code than hString2Char because use of switch/case instead of if/then/else). Perhaps it should be a good option too.

Sam & David – I don’t want to pounce on the performance issue too much, after all my main point was about robustness and compatibility, not performance (which indeed is use-case dependent). But just for the record, please read Hanan’s recent comment about how repeated use of verLessThan turned out to be a performance bottleneck in his code.

Yair, note that there are cases where your doSomethingWith will itself slow down, just by virtue of being inside a try/catch block – for example, if it contains any in-place optimizations (which are disabled when run inside a try/catch block).

You might want to rethink that statement about version 2 being faster. It’s only slightly faster in the new release where you are effectively doing a needless check. However, it’s a lot slower (total time in my example) in the old release where the error will occur inside the try/catch. If you are trying to support old releases as well then the try/catch could have just introduced a big performance degradation. Obviously all comes down to usecase.

%% Version 1
nThings = 1e4;
tic;
for iThing = 1:nThings
    if verLessThan('matlab', '9.1')
        % nothing to do in old release
    end
end
toc;

%% Version 2
tic;
for iThing = 1:nThings
    try
        % try to run function in old release which will error because it doesn't exist
        someFunctionThatWillErrorInOldRelease
    catch
    end
end
toc;

David – I can understand where you’re coming from, but my experience with the code that I write is different. Consider the following code snippet for example:

% Version 1:
if someCondition()
   data = doSomethingWith(data);
else
   % do nothing in this specific case because...
end

% Version 2:
try
   data = doSomethingWith(data);
catch
   % do nothing in this specific case because...
end

In this case, Version 1 might fail to do the expected thing if you have a problem (bug or exception) in either someCondition() or doSomethingWith(). On the other hand, Version 2 will, in the worst case, keep data unchanged and then proceed with the rest of the downstream processing. For many (but certainly not all) use-cases this would be better than erroring-out on an exception, as in Version 1. Version 2 is also faster than Version 1 due to the avoided condition checks (some checks could take a noticeable time to execute).

Perhaps the question is a matter of expertise level: just as inexperienced drivers should be much more careful in their driving than experienced ones, so too should inexperienced programmers be more careful in their programming while experienced developers have more leeway.

It’s Easier To Ask Forgiveness Than To Get Permission.