I think he's talking about garbage collection, which is often perceived as slow.
But you can certainly have automatic memory management in C++ as well. Stack-allocated objects manage themselves, for dynamically allocated objects one can use scoped/shared pointers. One added perk is that you can extend this approach to deterministically manage not only memory, but any other resource that can be acquired and released (e.g. locks). I actually like this approach very much. The only problem I see there is that since you're still using raw pointers, the runtime can't really move things around for efficiency since that would invalidate the pointers. But in a garbage-collected language that doesn't expose pointers, the heap can be defragmented during runtime, which is nice.
> The only problem I see there is that since you're still using raw pointers, the runtime can't really move things around for efficiency since that would invalidate the pointers.
The biggest downside is not really efficiency but that you lose the memory safety of a managed language doing this.
True, but most of these issues can be mitigated by using best practices - use vectors instead of raw arrays, avoid shared ownership (and use shared pointers when you can't), etc. Of course, these don't make the language safe, but they do help alleviate the problem a great deal.
I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages. I mean, we already can detect some problems using static code checking tools (i.e. PVS-studio), so it must be feasible.
> I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages.
Rust does this. :) It is not easy to get right—the borrow checker required a lot of design work to achieve the right balance between expressiveness and practicality—but I think we've shown that it is possible.
Arrays are bounded. You can usually disable bounds checking locally if you really need the extra ms, for cases the compiler is not able to optimize them.
Proper strings instead of char pointers that might be null terminated or not.
Var parameters and unbounded vector parameters to handle arguments that need to be changed.
Oberon family has already proven it is possible to write desktop operating systems in GC enabled systems programming languages.
Now as you say, many of these things are possible in modern C++. The problem is getting everyone on board, specially when dealing with old code bases littered with C like constructs.
But you can certainly have automatic memory management in C++ as well. Stack-allocated objects manage themselves, for dynamically allocated objects one can use scoped/shared pointers. One added perk is that you can extend this approach to deterministically manage not only memory, but any other resource that can be acquired and released (e.g. locks). I actually like this approach very much. The only problem I see there is that since you're still using raw pointers, the runtime can't really move things around for efficiency since that would invalidate the pointers. But in a garbage-collected language that doesn't expose pointers, the heap can be defragmented during runtime, which is nice.