I don't know that that's really the whole story. I mean, C++ has smart pointers that do reference counting, same as Rust's do.
But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.
That's true, a lot of Rust's features do exist in C++. I guess the main difference is that Rust is safe by default and you have to go out of your way to be unsafe. C++ is basically unsafe by default. In C++, the standard syntax for allocating memory gives you a completely unchecked pointer that you can freely use from whatever thread you want.
> or return a pointer to a local variable that's about to go out of scope
I thought of that recently. I wonder about using escape analysis to detect that and simply don't release the stack frame until the reference goes out of scope.
Static analysis/tracing absolutely can do a bunch of that kind of thing, particularly catching trivial cases.
But I think it's still a pretty important upgrade when those things are being checked by the compiler, for free, with guarantees, as part of every build, rather than using some side-tool that may be proprietary, deliver oodles of false positives, and so on.
What I mean is just fix that so it works. If you have split stacks the one for data doesn't have to track function call chains.
The advantage of using analysis tools is you only pay for that once. Not with every compile. And the tools are smarter than Rust. You also don't have safe vs unsafe code like you do with Rust.
You wouldn't just need split stacks for this, you'd need a spaghetti stack with some kind of heap allocation for frames. At which point perf goes out of the window already.
If you are using gcc, clang or vc++, to certain extent that is part of the compiler.
Just like C, following the UNIX principle, had compiler, assembler, linker, makefile, and linter since 1979. But people kept forgetting about the last piece of the puzzle and now it is a pain to bolt into existing code.
But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.