This really is a general discussion unless you share with us what kind of structures you are really using for storing the data.
If they are arrays they typically reside on the stack and not the heap memory (unless you specifically require the memory for it with malloc or PSRAM memory with ps_malloc). The full amount of memory is allocated at start regardless how much data you really put into it. If you want to know how much stack is still left free you can use uxTaskGetStackHighWaterMark (NULL).
Stack memory is allocated to each task (process) when it is created. If your default task (setup (), loop ()) does not have enough stack you can start a new task on your own and allocate it as much memory as needed.
If you are using vectors they usually use just a little of the stack and put all the rest on the heap. They usually require as much heap memory as really occupied by useful data. Checking the free heap has already been answered here.
Do you have a reference to backup that claim? I believe that unless the objects themselves dynamically allocate memory on the heap (eg String, std::vector, etc), then non-static, function-local objects are stored on the stack in their entirety. That’s regardless of their complexity or size.
This is correct. I guess the discussion is more about how class instances get created.
class myClass {
public:
int myInt;
};
int main() {
myClass A; // instance A resides on the stack
myClass *B = new myClass; // B points to the instance on the heap
I don't think there is a difference between classes and ordinary variables, arrays or structs:
class myClass {
public:
int myInt;
};
myClass S; // Class is created in RAM during compile time
int intS; // the same for the int variable
int main() {
myClass A; // instance A resides on the stack
int intA; // variable resides on stack
static int intB; // variable is created in static RAM area ( like global variable )
myClass *B = new myClass; // B points to the instance on the heap
int *intH = new int; // intH points to an int in heap
That’s something that really bugs me. people applying hardware overkill to solve problems that these 8-bit 16MHz micros can easily handle with decent code !