To really make string_view sane and safe, you'd have to make std::string reference counted (with each string view holding a ref), but I can't see that being popular.
This is a classic misuse of rvalues so I’m not sure it’s a huge problem. I don’t think it’s a problem with C++. I probably work at the same place you do btw and I am pretty sure there are rules/guides about how to handle string_view lifetimes
For those downvoting, please explain why you think string_view should take ownership of an rvalue string
Do you know if they're revisited this ever since string_view was implemented? I feel like a vector<string_view> should be quite uncontroversial, and you could even propagate the allocator from the string to the vector.
std::string_view can optimize both performance and code readability in code sections which handle strings. However it can also lead to UB and to memory issues if used incorrectly.
C++ stdlib didn’t have string_view for ages. Also, until recently, C++ sucked for things like convert to/from strings and string buffers. std::stringstream is awful.
C++ code usually use std:: string, std::string_view, or other string classes that stores the string size and has some capacity pre-allocated to avoid such issues.
I think the issue with string_view is less laziness and more recency: most libraries still need to support C++ versions prior to C++17. Rust had the advantage that slices were there from day one.
That code is older than C++11, let alone C++17. Also, your proposal isn't as efficient, since it calls strlen on construction of string_view (not that cost of parsing command line arguments is going to be measurable).
Agreed. 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).
Is it just me, or does it seem like std::string_view is just an alternative in semantics to a `char *` plus a size? It doesn't null-terminate (which would require copying or mutating). Is there some extra safety checking this provides?
> The same is probably true for anybody coding C++ using modern library facilities. There is just no temptation to do anything dodgy.
std::string_view is but the latest example of a "modern" C++ facility that turns out to be a dodgy footgun, due to the lack of safeguards around lifetime errors. C++ still lacks a general equivalent to string_view for arrays (what Rust calls a slice) for the same reason. These seem like significant drawbacks to me.
Rust (mostly) makes you do it right. C++ happily lets you pass a temporary string to a function taking string_view and blowing yourself up. "Just use smart pointers everywhere" is not actually sufficient to prevent serious bugs.
Tip #1 appears on the surface to be about C++17's std::string_view, but many shops had something similar to string_view for a decade or more before C++ made it official. The tips are not presented in their original form; edits have been made (as per the linked page). I think Google had something like string_view by 2009 at the latest, using C++03 compilers.
reply