Think of string_view as a non-owning pointer to a known-size array. If the array is moved or destroyed, then string_view is left dangling... just like a pointer.
something similar was initiated by herb-sutter as well in his 'guru of the week' (gotw) columns. which then became books in their own right aka 'exceptional c++' series.
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.
> Yes. It is a small step from the well-worn convention to pass each char* around with its length.
kind of surprising to note that implicit 'string_view' conversions are now regarded as a good thing?
on a side note, the language is _complicated_, and shows no signs of stopping ! 3 articles on move/copy ctor's and only one that applies to programming in general.
And they also claim string_views can be constructed from a std::string. That's true of their implementation and it's true of the TS string_view but it was removed from the c++17 string_view.
Both series have been created over many years, so I'm not sure which one is more modern. Herb Sutter says that all GotW articles are being revised to reflect changes in C++14.
Herb Sutter's recent tips are more modern (and the backlog is being updated).
Scott Meyers' Effective Modern C++ is a great successor to his Effective C++ book which spawned the whole "Effective *" snowclone books and covers C++14, though not 17, of course.
Actually, this blog post's content looks like a watered-down version of a tip from either or both of the above authors, though I'm too lazy to chase down a verification.
> We’ve decided to expose most of these tips to the Abseil development community, and the C++ community at large. Over the coming months, we’ll be posting new tips as we review and refine them for publication. Not all the entries we’ve written are relevant to the outside world; some were specific to our internal tools and abstractions, and some have become obsolete as the language has changed.
> Consisting of the foundational C++ and Python code at Google, Abseil includes libraries that will grow to underpin other Google-backed open source projects like gRPC, Protobuf and TensorFlow.
This library already seems like it is suffering from scope-creep. Tensorflow, gRPC, and Protobuf are hardly related to improving the C++ standard. Why are these even in the same library at all?
Published every weekday!