title: Fundamental limitations of cell arrays, arrays of structs, and scalar structs?
body: <p>I've been using Matlab on and off for decades.  I thought I had a good grip on arrays, structs, cell arrays, tables, an array of structs, and a struct in which each field is an array.  For the latter two, I assumed that each field needed to be of uniform type.  I'm finding that no such limitation exists:</p>
  
  <p><a href="https://i.stack.imgur.com/7GgfX.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/7GgfX.png" alt="enter image description here"></a></p>
  
  <p>Perhaps Matlab is becoming more flexible with the years (I'm using 2015b), but it does undermine my confidence in choosing the best type of variable for a task if I find that understanding of the limitations of each type is wrong.  For the purpose of this question, I can't really articulate the needs of the task because the manner in which I break down a large to-do into tasks depends on my understanding of the data types at my disposal, and their advantages/limitations.</p>
  
  <p>I can (and have) read online documentation ad nauseum, and while they will walk you through code to illustrate what the data types are able to do, I haven't yet come across a succinct description of the comparative limitations between cell arrays, arrays of structs, and structs whose fields are themselves arrays -- to the point that I can use that knowledge to choose the best structure in a given situation.  Basic stuff, I do find, e.g., the same field names will occur in each struct of a struct array (but as the above example shows, each field of each struct can contain highly heterogeneous data types and/or array sizes).</p>
  
  <p><strong>THE QUESTION</strong></p>
  
  <p>Can anyone point to such a comparison of limitations between cell arrays, arrays of structs, and scalar structs whose fields are themselves arrays?  I'm looking for a treatment at a level that informs a coder in deciding on the best trade-off between (i) speed, (ii) memory, and (iii) readability, maintainability, and evolvability.</p>
  
  <p>I've deliberately left out tables because, although I'm enamoured of their convenient access to, and subsetting of, data sets (and presentation thereof), they have proved rather slow for manipulation of data.  They have their uses, and I use them liberally, but I'm not interested in them for the purpose of this comparison, which is under-the-hood algorithm coding.</p>