Would it make sense to have a zstring_view for such cases? It'd be a null-terminated variant of string_view. Obviously it'd be less generic then string_view but as C functions aren't going anywhere any time soon it might still be handy.
what is the result of zstring_view("Embedded\0Here").size().
On Wednesday, May 13, 2015 at 10:39:56 AM UTC-4, Nevin ":-)" Liber wrote:what is the result of zstring_view("Embedded\0Here").size().In order to maintain invariant that strlen(zs.c_str()) == zs.length() it would have to be 8. That is whenever you construct a zstring_vew from a string_view the implementation must scan the string for nulls.
On 14 May 2015 at 20:47, Matthew Fioravante <fmatth...@gmail.com> wrote:On Wednesday, May 13, 2015 at 10:39:56 AM UTC-4, Nevin ":-)" Liber wrote:what is the result of zstring_view("Embedded\0Here").size().In order to maintain invariant that strlen(zs.c_str()) == zs.length() it would have to be 8. That is whenever you construct a zstring_vew from a string_view the implementation must scan the string for nulls.If that is your invariant, then I really don't understand your zmstring_view idea.
Do you plan on checking every write to make sure none of them write a '\0'?
So, you want to add an entire new type, just so that you don't have to type `.c_str()` after a std::string?
Equally importantly, `zstring_view` would not be a very useful view class by itself. It's API will be more limited than an actual `string_view`. You can chop of leading characters, but you can't do anything more than that, since it has to be null-terminated. You could never do Regex searches that return `zstring_view`s. And so forth.
Personally, I prefer option 2. The user has to allocate memory, but they don't have to put it there explicitly. It happens invisibly as a temporary. Or at least, it can, depending on the source type.
On 13 May 2015 at 06:13, Olaf van der Spek <olafv...@gmail.com> wrote:Would it make sense to have a zstring_view for such cases? It'd be a null-terminated variant of string_view. Obviously it'd be less generic then string_view but as C functions aren't going anywhere any time soon it might still be handy.I rather see something like this come from experience rather than invention It is unclear how useful it would be in practice. There are also some rather obvious interface questions, such as what is the result of zstring_view("Embedded\0Here").size().
Op woensdag 13 mei 2015 16:16:07 UTC+2 schreef Nicol Bolas:So, you want to add an entire new type, just so that you don't have to type `.c_str()` after a std::string?Yes. Are types too expensive for that?
Equally importantly, `zstring_view` would not be a very useful view class by itself. It's API will be more limited than an actual `string_view`. You can chop of leading characters, but you can't do anything more than that, since it has to be null-terminated. You could never do Regex searches that return `zstring_view`s. And so forth.Obviously such functions would return a regular string_view.Personally, I prefer option 2. The user has to allocate memory, but they don't have to put it there explicitly. It happens invisibly as a temporary. Or at least, it can, depending on the source type.I am not a fan of such unnecessary allocations.
Why do you prefer 2? Do you agree that not having to use ().c_str() is a benefit?