I will say that you don't mention the dangling-view issue: as it is a view on some data, you must be sure that those data are still alive when you use the view.
Some time has passed since I wrote my article, and we (our team) have gained experience with std::string_view: the fact that you have no guarantee that they end with a \0 can lead so subtle bugs. This is especially true in our case because we interact we quite a lot of C code and simply calling data() is often a bad idea.
As the end of the day, I am less enthusiastic now than 1.5 year ago (but still enthusiastic of course ;) )
You know I wrote an article about this class (dev.to/younup/comprendre-std-strin...) and you may probably know what I am gonna say ;)
I will say that you don't mention the dangling-view issue: as it is a view on some data, you must be sure that those data are still alive when you use the view.
Some time has passed since I wrote my article, and we (our team) have gained experience with
std::string_view: the fact that you have no guarantee that they end with a\0can lead so subtle bugs. This is especially true in our case because we interact we quite a lot of C code and simply callingdata()is often a bad idea.As the end of the day, I am less enthusiastic now than 1.5 year ago (but still enthusiastic of course ;) )
Thanks for your comment. Indeed, I think I mentioned that if you need that
\0you better stick with the type that guarantees it.I'm usually freaked out when I see
.data()in the code :)