I've read that malloc() should be avoided when designing FreeRTOS applications. Does the same apply when using "new"?
E.g.:
TestObject* test = new TestObject();
On a side note, can the FreeRTOS C files be compiled with a C++ compiler?
\$\begingroup\$
\$\endgroup\$
2
-
\$\begingroup\$ Do you think this question might better be posed on a programming forum? C and C++ are not the same thing, obviously. However, C++ knows about C, and I believe there is a way to inform the compiler that the source file is a C file rather than C++. But I am not a programmer. A programmer would know. \$\endgroup\$– user57037Apr 22, 2018 at 20:42
-
\$\begingroup\$ Yes it does. Both are heap allocation. Note that "should be avoided" doesn't mean "never use" but if you can re-structure the problem to avoid it, good. See also electronics.stackexchange.com/questions/146298/… \$\endgroup\$– user16324Apr 22, 2018 at 20:52
Add a comment
|
3 Answers
\$\begingroup\$
\$\endgroup\$
5
This isn't about malloc vs new, rather it is about "should you use heap allocation in an embedded system, or not?" which is more of a philosophical question.
Heap memory management is very useful from a programmer's point of view, however in an embedded / real time application, when an allocation fails, you're in trouble.
If all memory is preallocated (ie, statically), then you can prove that the software will never run out of memory. You can't prove it when using dynamic allocation. If you manage memory manually (which is a pain) there can also be memory leaks, double free's, and other fancy bugs. Additionally, since you are using a preemptive multitasking OS, you have to wonder if your memory allocator is thread-safe. If your code uses lots of allocations, overhead may be substantial.
Memory fragmentation is a real problem on long-running systems, too. And this one is quite subtle. You need an allocator designed to mitigate this, but it will only work if the allocations are small enough in size.
So... it's a tradeoff. You have to think about the details.
-
\$\begingroup\$ One of the memory management schemes which come with FreeRTOS include coalescing fragmented memory. Although I suppose it still needs some headroom over static allocation. And it is thread-safe. Also - considering static allocation thread stack memory can still be an issue - to not use too little. That said coming from an OS backround "memory fragmentation" has always been a bogeyman for me ;) \$\endgroup\$– jaskijApr 23, 2018 at 7:32
-
\$\begingroup\$ Interesting! Can it move allocated blocks around in order to coalesce free memory? \$\endgroup\$– bobfluxApr 23, 2018 at 11:40
-
\$\begingroup\$ So far I only noted it's existence, but I don't believe so - wouldnt moving them around require a trap or an MMU, something beyond the capabilities of Cortex-M? It's called heap5 from what I remember - being on my first project in FreeRTOS I opted for fully static allocation. \$\endgroup\$– jaskijApr 23, 2018 at 11:50
-
\$\begingroup\$ only coalescing. And it's heap4 - heap5 adds the option of using multiple regions for heap (could be useful with Cortex-M4 and M7 CCM) \$\endgroup\$– jaskijApr 23, 2018 at 14:49
-
\$\begingroup\$ "If all memory is preallocated (ie, statically), then you can prove that the software will never run out of memory." - How about in the case of a stack overflow? \$\endgroup\$– M-RMay 11, 2018 at 20:05
\$\begingroup\$
\$\endgroup\$
The issue is that dynamic memory support on embedded systems is often very limited. If you are working on a platform where it is advised to avoid malloc, then you should also avoid new as well.
There's no requirement in C++ to implement new and delete in any particular way, but generally the default implementations will use malloc and free under the hood.
\$\begingroup\$
\$\endgroup\$
There can be problems in compiling C files with a C++ compiler. For example, C++ has extra keywords such as "class" and "new" that could, in C, be used as variable or function names and would cause an error if compiled with a C++ compiler. The usual way around this is to surround the C code with constructs such as:
#ifdef __cplusplus
extern "C" {
#endif
// C source code
#ifdef __cplusplus
}
#endif
C++ compilers predefine __cplusplus to be non-zero, whereas C compilers do not define it.
If you check the FreeRTOS source and header files you will find that this has already been done, and so it should be safe to compile it with a C++ compiler.
