-1

C++17 string_view has this better syntax where we don't have to use this ugly long const std::string & when passing our text to function. But I don't really understand if this function can be used in code that is mixed with C, like printf function. My concern it that member function data() does not guarantee we have null terminating character. The code I'm talking about is not performance critical, but has to be robust.

So my question is, is there any advantage from using it, or is it even worse than simple const std::string &? I see that it is recommended to use everywhere, but in case like mine it adds this layer of uncertainty that it could crash a program.

konradk
  • 161
  • 1
  • 9
  • 1
    Related/possible duplicate: [Using std::string_view with api that expects null-terminated string](https://stackoverflow.com/q/41286898/11082165), and all of the dupe targets for [container of string_view's - are they always null-terminated?](https://stackoverflow.com/q/69827333/11082165) – Brian61354270 Feb 09 '23 at 17:07
  • Are you open to using the [GSL](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-gsl)? There's [`gsl::zstring` and `gsl:czstring`](https://github.com/microsoft/GSL/blob/main/include/gsl/string_span) to consider. – Brian61354270 Feb 09 '23 at 17:11
  • *"better syntax where we don't have to use this ugly long const std::string & when passing our text to function"* - yeah, `const std::string_view` looks much shorter – user7860670 Feb 09 '23 at 17:17
  • @Brian unfortunately no – konradk Feb 09 '23 at 17:38

1 Answers1

1

In general std::string_view::data() does not guarantee zero termination of the data refered to by the std::string_view.

From the documentation Notes section:

Unlike std::basic_string::data() and string literals, std::basic_string_view::data() returns a pointer to a buffer that is not necessarily null-terminated, for example a substring view (e.g. from remove_suffix). Therefore, it is typically a mistake to pass data() to a routine that takes just a const CharT* and expects a null-terminated string.

(emphasis is mine)

The following short program demostrates it:

#include <string_view>
#include <iostream>

int main() {
    char str[] = "abcdefghij";
    std::string_view sv{ str, 2 };
    std::cout << sv << std::endl;
    std::cout << sv.data() << std::endl;
}

Possible output:

ab
abcdefghij

Live demo

Note that sv is only 2 characters (and std::cout prints it well), but when you access data() and attemtping to print it there is no zero termination where it is supposed to be. In this specific case (which is by no means a general rule) the zero termination comes eventually along the buffer from the char array str.

However - If your std::string_view is initialized to a whole (complete) zero terminated string (like a char array or std::string), then the data() pointer will probably "inherit" the zero termination from it. I am not sure if it is implementation depenedent.

wohlstad
  • 12,661
  • 10
  • 26
  • 39
  • 1
    This answers the question "is std::string_view null terminated?", which isn't what was asked. The OP seems to be aware that it is not, since they write as much in the question: _"my concern it that member function data() does not guarantee we have null terminating character"_. This question is asking, subjectively, whether the benefits of `std::string_view` outweigh the risk of mishandling strings that should have been null-terminated, in their particular use-case. – Brian61354270 Feb 09 '23 at 17:28
  • I understood _"my concern it that member function data() does not guarantee we have null terminating character"_ to mean the OP has doubts whether it offers this guarantee. I may have misunderstood. – wohlstad Feb 09 '23 at 17:30
  • @Brian exactly. I was expecting some kind of answers like "in my company we stay away from std::string_view, because it adds more complexity, where one has to think if he should use std::string or std::string_view" but I guess I asked the question in a wrong way. – konradk Feb 09 '23 at 17:36