[flohofwoe]

One problem I have with memory-managed languages for writing high-performance-code is that you need to give up the simplicity of not having to care about memory management. You need to know exactly how the garbage collector in this specific language (and current version of the language) works, and how to build your code around that. The resulting 'mental burden' is the same or even bigger as in C or C++, and the resulting code often looks worse then C++ code which does the same. An extreme example of this is asm.js, much higher performance than typical JS since it only uses numbers, not JS objects (and thus basically removes the need for garbage collection), but so much different from manually written JS that it is basically a different language.

As for smart pointers in C++: they are only useful in a code architecture that essentially emulates C# or Java (all objects as single entities on the heap) using C or C++ in such a "memory-managed style" really doesn't make much sense since it will be slower then a GC. The point about manual memory management is to reduce dynamic allocations as much as possible and have all your data either on the stack or in long-lived, big memory chunks. If you need to allocate and deallocate all the time, or track the ownership and lifetime for every little memory chunk, you're not using C/C++ to its advantage.

PS: C# for tools is great though (not so much because of the language, but because of the standard framework, which is much nicer than the C++ stdlib).

[edit: typos]

[pjmlp]

Just like you need to know how malloc()/new/STL allocators for your specific C or C++ compiler are implemented.

And most implementations actually suck at multi-threaded code, to the point there are companies selling better implementations of them.

> The point about manual memory management is to reduce dynamic allocations as much as possible and have all your data either on the stack or in long-lived, big memory chunks.

Also possible in GC enabled languages, grated not available in all of them.

As former C++ dev, I can guarantee you that unless you write 100% of the code yourself, there will be leaks, double frees, delete calls instead of delete[] ones, releasing unallocated memory and totally lack of control of third party leaks.

[flohofwoe]

The point I'm trying to make is that you loose the advantage of a garbage collected language once performance becomes important, so there's no point in using such a language for high-performance code in the first place.

Integrating third party dependencies into C++ is its real achilles heel, I agree. I only accept dependencies that come with source and either don't allocate dynamic memory at all, or allow full control over allocation by providing custom hooks. I also learned over time that typical C code is usually much easier to integrate than typical C++ code (which very often is an over-engineered template mess).

The way to deal effectively with memory management bugs is to allocate as little as possible. There are good analyzer and runtime tools (for instance the new runtime memory debuggers in Xcode and Visual Studio, the static analyzers, the clang address sanitizer in Xcode etc), these provide a much better view on what's going on under the hood than most managed-language-tools. And those tools make it quite trivial to catch most memory-related bugs. If you're doing hundreds-of-thousands of allocations it becomes much harder though, because than the problems will be lost in all the noise.

It is a valid argument though to use higher-level languages in high-level gameplay code, but this should only do scripting-style stuff, glueing subsystems and game objects together. Up in this area I don't want to care about ownership and lifetimes. It's important to find the balance though where the high-level code should better be moved into a low-level, central system.