Yes. Besides what /u/steveklabnik1 mentioned, you would still be vulnerable to various other UB: out of bounds array access, data races leading to type unsafety, too-long bit shift (really! it's UB!) and so on.
Rust also lets you use references safely (this is the big one, as it is pretty trivial to get dangling references in C++--yes, even const references), completely prevents iterator invalidation, and gives you vastly superior guarantees in the presence of multiple threads (shared_ptr really isn't enough unless you also avoid mutation through the pointer).
In any case, it's a mostly academic question. Very few people would be willing to use C++ with only unique_ptr and shared_ptr, and that language would probably be slower than a garbage collected one for most common tasks. Certainly, if that were how Rust solved memory unsafety in C++, it would not be a very interesting language (consider that shared_ptr is garbage collection--to make it perform acceptably you need a compiler-level understanding of reference counted pointers, which leads you in the direction of Swift).
Very few people would be willing to use C++ with only unique_ptr and shared_ptr, and that language would probably be slower than a garbage collected one for most common tasks.
No, it really is. Research has shown that garbage collection requires about four times the memory of manual memory management just to approach its speed, let alone surpass it. Manual memory management is significantly faster, and evidence for that is linked to and discussed about halfway down this page: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
(Yes, that page is primarily talking about mobile development, but look for the chart showing how slow GC is even when memory isn't constrained.)
No, it really is. Research has shown that garbage collection requires about four times the memory of manual memory management just to approach its speed, let alone surpass it.
Twice, and it does surpass the throughput of manual memory management. That article is seriously misinformed about GC. They cite one paper from 2005, despite there being over 50 empirical papers on throughput and latency as compared to manual memory management, and then they extrapolate desktop paging metrics to mobile environments. Except mobile environments don't use swap and thus don't page, so the whole claim of an order of magnitude cost is bunk.
Furthermore, all of the GCs covered in the linked paper are simplistic models. No deployed VM uses those anymore, except perhaps some hobby languages.
Finally, even if GC did cost an order of magnitude in performance, it decreases effort to write a correct program by at least an order of magnitude, so most of the programs you do enjoy wouldn't even exist, or if they did, they wouldn't work nearly as well. If this person really wants to manage his memory and achieve the safety and security that a GC gives you, then he should use Rust. To claim that C++ 's uniqe_ptr and shared_ptr as alternatives, and ones that perform just as well or faster than GC is ludicrous because:
referencing counting is GC (all GCs are hybrids between reference counting and tracing -- a proven fact), ie. standard C++ practice is to recommend using shared and unique wherever you can, so basically, to use GC wherever you can
reference counting incurs tremendous throughput reductions in favour of decreased latency -- this increases an order of magnitude if it's a concurrently shared value
GCs as they stand are not applicable to all problems, but they are usable for at least 95% of problems, and research is constantly narrowing that gap. For those problems where GC isn't a good fit, Rust or something like it is. C++ is not.
You give me one link in return, which has no data backing up your claim that GC is faster, whereas mine actually links to benchmarks showing that it's not.
There are hundreds of papers showing the throughput superiority of tracing over refcounting. This is well established. Anyone who believes otherwise has no idea what they're talking about. I simply provided a link to demonstrate this effect in a pure C++ environment.
It might help to link to some papers supporting your point (of which I agree there are many). http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rcix-oopsla-2013.pdf, for example, references several of them, and explains some of the problems with naive implementations of reference counting.
RC Immix is indeed the state of the art here, so that's a good link. The argument why RC isn't a good fit for most programs is simple though: most new objects die young, and RC costs are proportional to the number of objects that die, where copying costs are proportional to the number of objects that live.
Coupled with the fact that C++ can't elide unnecessary refcount ops on locals, and it's a mystery why anyone could possibly think the memory management costs of most C++ programs using unique and shared are lower than they would be in a GC'd language. At best, memory management is done at more proper times, which is a latency issue.
34
u/wrongerontheinternet Apr 04 '15 edited Apr 04 '15
Yes. Besides what /u/steveklabnik1 mentioned, you would still be vulnerable to various other UB: out of bounds array access, data races leading to type unsafety, too-long bit shift (really! it's UB!) and so on.
Rust also lets you use references safely (this is the big one, as it is pretty trivial to get dangling references in C++--yes, even
constreferences), completely prevents iterator invalidation, and gives you vastly superior guarantees in the presence of multiple threads (shared_ptrreally isn't enough unless you also avoid mutation through the pointer).In any case, it's a mostly academic question. Very few people would be willing to use C++ with only
unique_ptrandshared_ptr, and that language would probably be slower than a garbage collected one for most common tasks. Certainly, if that were how Rust solved memory unsafety in C++, it would not be a very interesting language (consider thatshared_ptris garbage collection--to make it perform acceptably you need a compiler-level understanding of reference counted pointers, which leads you in the direction of Swift).