yes but it's explicit, you have call special kernel routines and manage the memory yourself, it's not hidden in some library somewhere causing 500 new/deletes outside of your knowledge .... I've certainly met programmers in the past who have not internalised that new/malloc are a couple of orders of magnitude more expensive than other language primitives like + .... and had to show them how to profile .... and discover that 90% of the time our large multithreaded app was spending was in malloc .... inside their bespoke strings package .... and that statically allocated strings on the stack and strncpy were perfectly good for 90% of what they were doing with strings and didn't spend any time at all time in low level heap mutexes
I mean, the C standard library internally mallocs a bunch too, which is (one of many reasons) why the kernel has it's own modified version of a subset of the C library. If it were written in C++ the same rules would apply. When I was the lead for a C++14 RTOS that was MISRA compliant I had to write a custom collections library that's much more explicit. It's not that hard.
