3 ms·
Rust strings are in no way preferable to C++ strings I haven't been following Rust closely, so this is the first I've heard about the string/slice distinction.
by twoodfin 12y ago
Rust strings are in no way preferable to C++ strings
I haven't been following Rust closely, so this is the first I've heard about the string/slice distinction. But I have spent a lot of time trying to remove unnecessary allocations/deallocations/copies from performance-critical, string-heavy C++ code. I use a combination of custom allocators and slice-like objects, but both of these approaches make it a hassle to interact with code using the natural std::string.
A pervasive distinction between strings that manage their own memory and those that don't, along with language and library support to make using them in combination straightforward would be a big win for me.
- sanderjd 12y agoI think having felt pain with std::string, you would implicitly understand and enjoy working with the two string types in Rust. They do everything it sounds like you've been doing manually and inconveniently in your C++ code.
- megrimlock 12y agoAgreed. I'd also make an analogy to C++ where you sometimes must hop between std::string and char*'s with ambiguous lifetimes. Not to mention various custom string types that any big app will have (ex. one that internally exploits jemalloc's allocator optimizations (i.e. exposing block overages), or does rope-style allocation, or intern's into a shared table, or whatever).
- steveklabnik 12y ago> this is the first I've heard about the string/slice distinction Strings got re-done like ~2 months ago, so don't feel too bad ;)