beware malloc() free() on microprocessors. garbage collection (coalescing free'd blocks) is not done well, and is time consuming if done at all.
And deterministic control programs shun such.
best to instantiate classes and data structures at compile time in small micros. C++ if used as if the micro were a gigabyte PC, by naive programmers, will krump.
Serious system programming and real time/control, mission critical, most often on micros use C or very carefully crafted C++.
It's a grey area and widely debated - how much RAM one needs before going berserk with dynamic memory allocation and garbage collection.
Of course, in an ISR, one should't use malloc() or new()
I have never written a class before but am working on one for FIFO queues. I hope to be able to allocate the buffer for each instance (I am not sure of terminology) so that different queues using this class can have different size buffers.
I ran into symptoms that appear to be a problem with using malloc inside the constructor for the class. I blindly put an interrupt disable/enable around the malloc and this really seems to make the difference between the mallocs success and failure (returning NULL).
As long as I use the interrupt wrapper, I can declare multiple objects using my Fifo class and they seem to work properly.
I realize the problem could be something other than this and the slight changes in code just happen to appear to fix it, but I wonder if anyone knows if this could be a problem?
I find suggestions to use new/delete in place of malloc/free in C++. (In my application I never need to free up the allocation of the bufers.) I will look into trying new instead of malloc and see if that makes any difference.
Thanks,
Chuck