It shows a distinct lack of understanding of why people still use C or C++ to raise languages/environments like Go as viable alternatives.
It shows a distinct lack of understanding of why people still use C or C++ to raise languages/environments like Go as viable alternatives.
D is the one true C++ without pretending being a superset of C. Rust is more modern than C++ and better in programming in the large. But D is really for low level programming and a good target for code generation. For me it is a good replacement for C++ and Delphi. It is even a good fit for areas touched by Java and C# like desktop and scientific apps. But it is not there yet because of lack of serious tooling and lack of bytecode but for the second disadvantage you earn performance. Nimrod for example could address this (with D as a code generation target).
Malloc() and free() aren't exactly predictable. If you really want guarantees, you need to write your own custom allocator, and if you don't need those guarantees, garbage collection is probably enough for your purposes.
Basically, if you're using C++ without real manual management, with custom allocators, pools, and all, you probably didn't need C++ in the first place.
This is not to say that the underlying allocator is necessarily deterministic, but you're making a false dilemma here by putting it in opposition to making decisions about custom allocators and pool allocators. You can use RAII with custom allocators. You can use RAII with memory pools.
And that's where C++ really does shine. It's a niche that hasn't even really been attempted much, let alone that it's been surpassed in.
void main() @nogc { /* ... */ } // this program doesn't use the GC