eval evaluates a valid Matlab expression which is defined by a string.

Imagine the following:

name = 'myVar';
nominal = 42;

when you now call:

eval([ name '=' num2str(nominal) ';' ]);

which is the same like:

eval([ 'myVar = 42;' ]);

you get a variable myVar in your workspace which has the value 42.

The same happens, when you type in

myVar = 42;

directly. So instead of having a line of code in your script, you can just evaluate a code-string from wherever. In your case it is used to create a variable from two struct fields, the first the variable name and the second it's value.

---

Another example, you want a variable named after it's actual value. But you don't know its name before:

value = randi(10);
eval([ 'var' num2str(value) '=' num2str(value) ';' ]);

The only way to do this is by using eval as you need to create a code-line-string according to the random generated value. Eval then "writes" it. If for example value = 9, it is stored to a variable var9 in the next step.

It causes cancer.

You totally misunderstand the issue if you think that |eval|, |evalin| or |assignin| are faulty. There is nothing wrong with |eval|, |evalin|, or |assignin|, in the sense that _they work exactly as documented and do exactly what they are supposed to do_. Sometimes these functions are useful. But... The problem is that _what_ they do lets *many beginners use them totally inappropriately, to solve tasks that would be much better solved using simpler, faster, neater, more efficient, easier to debug and much more robust methods* (usually indexing is the simpler solution). Simply put, those beginners design their code in such a way that they force themselves to write bad code: slow, buggy, hard to debug, insecure, complex, ugly code. By deciding to write such bad code they remove all of the inbuilt code checking and code helper tools. They also remove any ability for the JIT compiler to speed up their code. They remove the ability to search for and locate variables. The list goes on. *Even if all other things were equal, any _one_ of these disadvantages would be reason enough to avoid dynamic variable names.* Or, to put it another way, the problem is _not_ using |eval| in particular, the main problem is _dynamically accessing variable names_. It just happens that magically defining or accessing variable names is most commonly achieved using |eval| and |assignin|, but the problem actually _occurs regardless of what tool or method is used to access them_: it also applies to |load|, for example, when |load| is called without an output variable. You need to stop asking "what is the problem with |eval|?", and start asking yourself "why is it so inefficient to dynamically access variable names?". To help understand some of the issues that is causes, read this thread: You are not the first beginner to ask this question. Some of them get really confused, because they think that there is a problem with |eval|. For example, read this discussion, including all of the answers and comments: _"The experienced contributors to the forum always emphasize avoiding usage of assignin and eval functions due to many reasons."_ You will notice that the title of my tutorial is actually "TUTORIAL: Why Variables Should Not Be Named Dynamically (eval)". All of the discussions and links within that tutorial are focused on *one* topic: dynamically accessing variable names. You need to start reading about this topic if you really want to understand it.

What is "SL_Excess_Fwd"? If it is not a string, but contains non-integer floating point values, the conversion fails here with the posted error message: Name = ['SL_Excess_Fwd' '_' num2str(RtnLen(rl)) '_SL_' num2str(SL_Per(slp))]; eval([Name, '=', SL_Excess_Fwd]) See: ['string', -1] Here the -1 cannot be converted to a CHAR value unequivocally. I think you want: eval([Name, '=', 'SL_Excess_Fwd']) % Quotes around the variable!   As Matt Fig has already mention, such problems are typical, when you use EVAL. It would be much smarter to use an index as index, instead of hiding it in the name of the variable: SL_Excess_Fwd(RtnLen(rl)).SL(SL_Per(slp)) = SL_Excess_Fwd Or at least a dynamic fieldname: SL_Excess.sprintf('Fwd%d', RtnLen(rl)).sprintf('SL%d', SL_Per(slp)) = SL_Excess_FWD;