6 ms·
I'd actually much rather read the opposite article: things that C++ excels at that Rust falls down on. I'm not an expert, but I think there's still allocation u
by moomin 12y ago
I'd actually much rather read the opposite article: things that C++ excels at that Rust falls down on. I'm not an expert, but I think there's still allocation use cases C++ is better at.
- humanrebar 12y agoOff the top of my head: * C++ has more robust compile-time meta-programming facilities, at least for the time being. * C++ can generally include C (well, C89) code as-is with no translation layer. Rust's FFI is pretty inoffensive, but it's more work than a #include * It's easier to do the really dangerous stuff if you have a good reason to. You can actually call push_back on a std::vector without invalidating your iterators if you're careful. I've never seen it used properly in production code, but it's possible. At any rate, it might be more awkward to write equivalent code in Rust. Then again, maybe a deque is better than a vector for this use case, in which case I suspect that Rust is capable of a more optimal solution than push_back or std::back_inserter.
- steveklabnik 12y agoC++ can also easily bind to libraries written in C++, while Rust cannot. (those libraries need to expose a C interface for Rust to be able to)
- humanrebar 12y agoThat's true, though I blame C++ for its lack of a standard ABI more than I would blame Rust. Not that that helps if you're just trying to get work done.