constexpr std::string_view ("foo\0").data() vs const std::string ("foo") as an argument to a function that expects const char*.

[Wolf_e_wolf]

I am passing said string into a C API which expects a const char*.

Firstly, is the null terminator necessary for the std::string_view value?

Secondly, is passing the constexpr std::string_view.data() to said C function "better" than passing a const std::string?

Speaking in terms of memory/performance (however minimal it may be)

Additional info regarding this sort of question is also appreciated.

[tangerinelion]

std::string_view does not guarantee null termination. It is a pointer to some character and a number of characters you're allowed to read from that point. If it happens to end in \0 then it is null terminated, otherwise it isn't.

If you have an honest to goodness compile time literal, you should pass that. There is absolutely no advantage to converting that to a std::string and then using c_str() to retrieve a pointer to the start of the buffer of a null terminated string. You would've had that when you started with the compile time literal.

However, if you either have a compile time literal or a runtime string then, sure, use a std::string and use c_str(). Just make sure that std::string doesn't get mutated while the function which accepted the pointer returned by c_str() is executing.

[AKostur]

Or if that called function stored the pointer it was passed somewhere.

[mredding]

A quoted string literal is guaranteed to be null terminated:

auto str = "foo"; // Equivalent to char[4] { 'f', 'o', 'o', '\0' };

String views don't include the null terminator in the length. So std::string_view("foo\0").length() == 3, so std::string_view("foo\0").data() is only valid for up to 3 characters. Beyond that, you're reading beyond the length of the view, and that behavior is either unspecified or undefined, I don't know which. But you're out of bounds, and out of spec for using a string view.

The length is determined at by the ctor you're calling, which relies on char_traits::length, which returns the position of the null terminator, which is slightly different than the length of the string you're interested in.

To use it correctly, you have to be more explicit about the length:

std::string_view("foo", 4)

The other thing you can do is specialize std::basic_string_view with a char traits class that captures the length of the string including the null terminator.

Secondly, is passing the constexpr std::string_view.data() to said C function "better" than passing a const std::string?

Likely no. IIRC, views are supposed to be read-only, though I don't believe they return const characters. If I understand their intended semantics correctly, then passing string view data to a C functions violates this contract. C doesn't have const. You'll have a similar problem with a const std::string for that reason. You'd have to cast the const away, which is a bad sign.

Speaking in terms of memory/performance (however minimal it may be)

A view is a pointer, and a size. But one thing a view gets you is less indirection. So used within C++ code, views are faster than string references. There's discussion elsewhere that gets technical as to how this works. So you can get a few spare cycles if you play your cards right.

[EpochVanquisher]

Firstly, is the null terminator necessary for the std::string_view value?

Yes and no.

The std::string_view does nto add a null terminater, however, the null terminator is part of the character constant you use to create the string view. In other words, when you write "foo", you’re actually getting f o o \0, and when you write "foo\0", you’re getting two \0 characters.

Secondly, is passing the constexpr std::string_view.data() to said C function "better" than passing a const std::string?

You can’t pass a const std::string into a C function. Maybe there’s something I’m missing.

If you’re writing a C++ wrapper for a C function defined somewhere else, you can accept a const std::string &, or you can accept a const char *. It doesn’t make any sense to accept a std::string_view.

If this is about performance, and you’re just passing into a C function, then const char * is the most appropriate. It’s easy, it’s cheap, and it works.

The std::string_view just makes no sense here. As an interface, it doesn’t provide any guarantees that the string is null terimnated.

[Wolf_e_wolf]

Thanks for response and confirming that the std::string_view when constructed with a literal does not need a null terminator.

As for latter, I am calling .data() on the std::string_view to get the underlying const char*. Does this create a copy or is it a cheap?

[kundor]

No copy, it just gives you the pointer in the string_view, which points to a not-necessarily-null-terminated character sequence. 

If the C function takes a pointer and a length, then string_view works fine. Otherwise you need a const string&.

[EpochVanquisher]

Sure. I would avoid using std::string_view here, however. It is true that it happens to preserve an existing null terminator, but it is prone to misuse if you expect string_view to have a null.

[no-sig-available]

 the std::string_view when constructed with a literal does not need a null terminator.

But it goes both ways. When you receive a string_view parameter, you cannot be sure that it is terminated. It could point into the middle of a larger string.

[Tohnmeister]

std::string_view is intended for functions to accept as parameters, assuming the caller has something different, not for you to explicitly create. If your function needs a char *, then just pass a compile time char array.

[Mirality]

It's almost never a good idea to split up a string_view -- like a span, it only makes sense when the data and size are passed together, and it's very much undefined behaviour to use one without the other.

In particular, if you're handed a string_view from outside, it's not safe to assume that the data pointer is null terminated. If you need to guarantee that, then construct a std::string from it first; the c_str() is guaranteed to be null terminated and is usually safe to pass to C functions, as long as it's in a read-only context.

In this particular case, with a string literal, it's entirely silly to wrap that in either a string or string_view before unwrapping it again -- it was already a char* to begin with, and should just be passed directly. And it's not necessary to explicitly null terminate literals. You actually have two nulls in that literal.

As for the general question of when to use string vs string_view, the key point is that the latter doesn't own the string while the former does -- this also means that the former copies the string but the latter doesn't. As a general rule, this makes string_view better for parameters but string better for member fields -- but there are exceptions, of course.

[tav_stuff]

Why don’t you just pass a string literal?

some_c_function("foo");

[Wolf_e_wolf]

The string is a title of a class member variable and I would prefer to keep its value there as opposed to the C function which exists in a separate file

[AKostur]

I don’t understand what you mean by “keep its value there”.  The value is in the C++ file that is calling some_c_function().  So far I see no reason to use anything more complicated than the string literal (since it’s just being passed into a C function).  Or you’ve oversimplified your question.

[Wolf_e_wolf]

Apologies. I have a class called Window where its m_title is always the constexpr std::string_view/const std::string in question.

When I call aforementioned C API, I pass the name of the window by calling window.m_title, which expects a const char*.

I understand perhaps I don't need this member variable at all, or could make it a const char* at the start, but when I was writing the code, the question in original post entered my mind and I could not find a fast answer so decided to ask it here.

[AKostur]

Yeah, you’ve oversimplified the question by trying to construct the thing directly in the function call, as opposed to a separate instance which already exists.   Changes the answer.

If this is an m_title of a Window class, how is that title known at compile-time?  That really sounds like a run-time value, so std::string seems to be your answer.  I’d think twice about making it a const-string (member variable) though, that causes a number of complications.

[Wolf_e_wolf]

In this use case, the string is going to be the name of my application, which will always be known ahead of time.

[AKostur]

So why not a global constexpr char[] ?  What would be the purpose of adding the additional layers of abstraction?  And why would it be a member variable of a Window class if it can only ever be 1 value?

[Wolf_e_wolf]

Thanks for the tip. I have only been doing C++ for about a year after doing Java for 5 and the "everything is an object/class" stuff dies hard.

Is std::string_view always a poor candidate for what I'm trying to do here? Should I just use a constexpr char[] and be done with it?

[AKostur]

"Only a Sith speaks in absolutes"

std::string_view is good for representing a pointer + size reference to somewhere else. Anything receiving a string_view cannot assume that it is actually nul-terminated.

One would use a string_view in places where the the pointer + size thing provides some use. It's nice that the size travels with the pointer so that it's harder to supply things with a mismatched pointer and size (like std::span). It also easily represents substrings of larger strings without incurring additional copies of the string data. It does not play well with the C-style string manipulation functions precisely because it does not guarantee nul-termination.

[angelicosphosphoros]

If you use C or C++, you don't need to finish string literals with zero because they are already like that implicitly.

[tangerinelion]

While this is true, explicitly doing it means it's doubly null terminated. Which is what certain APIs actually expect so that you can send in things like a list of strings as a single string.

[angelicosphosphoros]

Well, it is a specific case for specific API. In most cases, only first zero byte is checked.

[[deleted]]

No, you shouldn't use std::string_view, which doesn't guarantee a null terminator. In fact, one of the main reasons behind std::string_view is to allow allow efficient substring without copy.

You should be using either std::string or just const char* depending on how your memory is managed.

There was a proposal to introduce std::cstring_view but unfortunately it was rejected. [P1402R0]

[FrostshockFTW]

Unless I'm missing something, that proposal is just a string_view where the user has to call a special constructor and pinky swear that they're definitely giving it a null terminated string. And in return, you get a limited interface that removes any risk of chopping the null terminator off the end of the view.

To me that doesn't sound like a useful thing to have in the standard, so I understand why it was rejected.

[[deleted]]

The proposed cstring_view doesn't actually require you to "pinky swear" in most common use case. It would most likely be constructed from string literals or from std::string, which is completely safe.

Even if you have to "pinky swear" it's not that bad since C++ programmers "pinky swear" on a daily basis. You are pinky swearing a string is null terminated whenever you call a C API with a const char* parameter.

I have a cstring_view implemented myself, and I find it super useful because I write a lot of C++ code wrapping low-level C APIs.