sd = structfun(@double, s, 'uniform', 0);
Now you have a numeric struct with the same field names, and can use whatever export method is suitable for that.
We do not know what you output file needs to look like, so it is difficult for us to recommend techniques.
And as mentioned above, putting each field in a cell array or converting each field individually will not work for larger structures.
Let us do some size calculations:
For a cell array, each entry is 104 bytes plus the amount of memory needed to store the data. For scalar double that is 8 bytes. So for a struct with N fields each with a scalar double, converted to cell, the total would be 112*N bytes for the cell array. You would probably also need a cell containing the fieldnames, which would be 108*N + (total number of characters in field names)*2 bytes
For a scalar struct array, each entry is 168 bytes plus the amount of memory needed to store the data. For scalar double that is 8 bytes. So for a struct with N fields each with a scalar double, the total would be 176*N bytes. This includes storage of the field names. Indeed, it works out exactly the same as 102 bytes plus 64 bytes for a field name (field names are maximum 64 characters but characters in field names are never permitted to have codes > 255, so they can be represented as one byte per character.)
So, if I understand your concern correctly, you can afford the memory for the struct, at 176*N bytes, but not the storage for the cell at 112*N + 108*N + (total number of characters in field names)*2 bytes?
Or is the concern that you cannot afford to have both the struct and the cell version in memory at the same time, that the struct uses more than half of all allocatable memory on your system? If so then that's something important to know, as it would constrain the techniques for writing to a file.
