Why would command syntax split string when using double quotes?

24 visualizzazioni (ultimi 30 giorni)
disp 'str ing' % good
disp "str ing" % error, Too many input arguments
I am on R2020a. It seems that the latter is equivalent to
disp str ing
I thought, at least
disp "str ing"
should be interpreted as
disp('"str ing"')
why would matlab split the string into several parts?

Risposta accettata

Walter Roberson
Walter Roberson il 28 Ott 2021
Not exactly. The latter is equivalent to disp('"str', 'ing"')
N 'str ing'
nargin = 1 varargin{1} = str ing
N "str ing"
nargin = 2 varargin{1} = "str varargin{2} = ing"
function N(varargin)
fprintf('nargin = %d\n', nargin);
celldisp(varargin)
end
why would matlab split the string into several parts?
Because that is what is documented:
With command syntax, MATLAB passes all inputs as character vectors (that is, as if they were enclosed in single quotation marks) and does not assign outputs to variables. To pass a data type other than a character vector, use the function syntax. To pass a value that contains a space, you have two options. One is to use function syntax. The other is to put single quotes around the value. Otherwise, MATLAB treats the space as splitting your value into multiple inputs.
In order for disp "str ing" to be treated as disp("str ing") then that would directly violate the rule that MATLAB passes all inputs as character vectors.
It does not explain why MATLAB does not convert the string into a character vector, as-if disp('str ing') had been called, but the documentation never implies anything like that would happen. Instead, the documentation talks only about single-quotes to include blanks, not about double-quotes.
It would not be unreasonable for MATLAB to be enhanced to handle double-quoted strings... but it is not a bug that it does not do so at the moment.
  5 Commenti
Steven Lord
Steven Lord circa 13 ore fa
We (MathWorks) went to a good bit of effort to make sure that functions that supported char row vectors prior to the introduction of string arrays behaved 'sensibly' (waving my hands a little bit) when passed in string scalars. It is true that there are some functions that behave differently; length, size, numel, and class are notable functions in this category.
f = @(x) cell2table({length(x), size(x), numel(x), class(x)}, ...
VariableNames = ["length", "size", "numel", "class"]);
charResults = f('MATLAB')
charResults = 1×4 table
length size numel class ______ ______ _____ ________ 6 1 6 6 {'char'}
stringResults = f("MATLAB")
stringResults = 1×4 table
length size numel class ______ ______ _____ __________ 1 1 1 1 {'string'}
But if you want to call for example something like strlength that 'knows' what to do with char vectors and strings, it returns a sensible answer on both char row vectors and scalar strings.
[strlength('MATLAB'), strlength("MATLAB")]
ans = 1×2
6 6
<mw-icon class=""></mw-icon>
<mw-icon class=""></mw-icon>
Command form is another place where the behavior does differ. I don't remember off the top of my head when this was discussed (and that discussion may have happened above my pay grade and/or among a different subset of MathWorks development than the design discussions I participate in) but I would be mildly surprised if it hadn't been discussed. Backwards compatiblity (not changing the behavior of commands that already accepted text including double quotes and treated those double quotes as part of the data rather than part of the syntax) might have factored into those discussions and the decision.
Stephen23
Stephen23 circa 10 ore fa
And then there is the behavior with (overloaded) operators, where they diverge quite significantly.

Accedi per commentare.

Più risposte (0)

Categorie

Scopri di più su Characters and Strings in Help Center e File Exchange

Prodotti


Release

R2020a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by