zstring_view

[tribal yew]

This is a reference implementation for a null-terminated string_view type two co-authors and I plan on proposing. It would be helpful to have it torn apart before we publish.

https://github.com/jeremy-rifkin/zstring_view/blob/main/include/zstring_view.hpp

[gusty hawk]

question, why is operator= placed among the constructors?
https://github.com/jeremy-rifkin/zstring_view/blob/main/include/zstring_view.hpp#L104

[tribal yew]

Good question, the reason is that it's the order in the standard for string_view https://eel.is/c++draft/string.view

The order makes some sense I think, special member functions then other constructors

[gusty hawk]

interesting

[shut summit]

copy assignment follows copy ctor, the ctors following that are not SMF

so it's just the smf grouped together I suppose

[gusty hawk]

LGTM

[gusty hawk]

i never thought about it like that, usually i do all ctors first

[waxen marlin]

what is the logic behind the max_size calculation

(npos - sizeof(size_type) - sizeof(void*)) / sizeof(value_type) / 4?

[shut summit]

heh, I've just been thinking about that as well

[tribal yew]

The logic is that I copied it from std::string_view

libstdc++'s string_view

[waxen marlin]

why is it dividing by 4

[waxen marlin]

libstdc++ defines max_size pretty weirdly from what I've seen

even has some bugs that let you create a std::basic_string which has a size greater than max_size

[tribal yew]

Hmm I see

Well, one thing I could do is just return basic_string_view<charT, traits>::max_size() and not have to worry about it

[waxen marlin]

if you're doing it just for consistency with string_view there should probably be a -1 added

[tribal yew]

Maybe add a -1 yeah

[waxen marlin]

for the zero byte at the end which must be there

[waxen marlin]

(-1 after dividing by sizeof(value_type))

[shut summit]

I dislike that your zstring_view has substr. You've already gotten rid of remove_suffix, which would also break the zero-termination premise - imho you should do the same to substr

that just seems to bug prone. If you really want a substr of a zstring_view, you should convert to string_view first and not magically return a string_view out of a sudden

all operations on zstring_view should preserve the zero-termination guarantee

[gusty hawk]

make a different substr that only allows removing the prefix?

[shut summit]

it's called remove_prefix

[gusty hawk]

that function returns void though right

[shut summit]

as it should, it mutates the string_view it's called on

[sacred rock]

more of a dumb question, how does the implemention differ from string_view? how does it solve the null terminator issue?

[gusty hawk]

so i'm saying there should be a substr that returns a zstring_view but only allows removing the prefix

[shut summit]

https://github.com/jeremy-rifkin/zstring_view/blob/main/include/zstring_view.hpp#L107

[sacred rock]

I see

[tribal yew]

The difference is that you have absolutely no way of knowing if string_views are null-terminated and people use .data() none the less in bug-prone ways. This class on the other hand has it as an invariant.

[shut summit]

another thing to note: this is missing a ctor from a range and iterator pair - in both cases the input may be zero terminated, you just have to check it

also this precondition should probably be expressed using contracts since you're targeting new C++ anyway

[tribal yew]

Not including a range or iterator constructor was intentional, I think they're bug-prone and the char*+size was already a concession. But I'm persuadable, I was talking with Peter about this (who is the other main author). We may also leave this to LEWG as an open question.

[tribal yew]

once a compiler exists for them, I want the reference implementation usable 🙂

[shut summit]

do you have a draft ready? it'd be easier to "review" with the intentions in writing

[tribal yew]

https://github.com/jeremy-rifkin/fiets/blob/master/papers/DX_zstring_view.fiets

https://github.com/dascandy/fiets/blob/master/papers/DX_zstring_view.fiets really, I linked my fork

[shut summit]

oh wow, hana co-authors?

[tribal yew]

Indeed 🙂

[shut summit]

nice, she's done a few really great proposals 🙂

[waxen marlin]

also is it intended to allow null terminators within the zstring_view, not just at the end

zstring_view s("a\0b",3); for example

[tribal yew]

Yes

Same as std::string

[spark helm]

why no remove_prefix/_suffix?

[waxen marlin]

remove_prefix is there

remove_suffix would generally break the null termination though

[spark helm]

it should return a normal string_view

[waxen marlin]

???

[limber sedge]

cppreference.com

std::basic_string_view<CharT,Traits>::remove_suffix

constexpr void remove_suffix(size_type n);

[waxen marlin]

they return void

[spark helm]

ah true

I always forget how unfortunate the string view api is

[waxen marlin]

there is substr which returns a normal string_view

[waxen marlin]

the string api is weird as a whole, like operator[] not being bounds checking but substr and many other functions doing bounds checking

and the existence of char_traits

[spark helm]

btw @tribal yew I would humbly suggest calling it cstring_view or cstr_view, for both consistency with .c_str(), and the fact that it's not a zero string.

[tribal yew]

That's my preference too. I added a note about this in the section on bikeshedding.

[spark helm]

I guess I'll add proposing the addition of .without_prefix/_suffix to my list ^^

[spark helm]

we should host a poll here 😛

[tribal yew]

Oh no

[waxen marlin]

someone will call it rigged again

should ping <@&331718482485837825> to make sure they know about it

[waxen marlin]

also wait, if it's called cstring_view then won't the literal suffix be "..."csv

csv file literal suffix

[spark helm]

lol

[waxen marlin]

was that not the motivation

confuse people by having a literal like "1,2,3"csv

[spark helm]

probably should just be "1,2,3"v

I'll also submit this one to your bikeshed section @tribal yew 😛

"bla" is already a C string, no need to repeat that fact 😛

[waxen marlin]

would "..."sv literals already be null terminated

[spark helm]

ideally they would have been

[waxen marlin]

if you just made string_view implicitly convertible to zstring_view/cstring_view then no need for new literals

[tribal yew]

So the funny thing is I actually started drafting a proposal for this back in august and sent it on the mailing list and people were like "this has already been proposed don't bother"

and I called it cstring_view with operator""csv 🙂

But Peter and others think times have changed so it's worth re-proposing

[spark helm]

hm there should probably be a way to decay a cstring_view to a normal string_view

[waxen marlin]

implicit conversion

[tribal yew]

We have operator basic_string_view

[spark helm]

I wonder whether it wouldn't be better to instead have a string_view ctor

[waxen marlin]

would it include stuff like adding overloads to existing library functions such as std::stol, std::locale::locale, etc. which currently require null terminated strings

[waxen marlin]

https://en.cppreference.com/w/cpp/string/basic_string/operator_basic_string_view exists

[tribal yew]

operator basic_string_view allows "foo"sv == "foo"zsv to work

And yeah, following the model of basic_string's operator basic_string_view

[spark helm]

k ^^

[waxen marlin]

at least I thought this was the primary purpose of proposals like this

[tribal yew]

I would like that, yes

We haven't written anything in the paper for it yet

[waxen marlin]

ok

[spark helm]

yeah, but that's not a view, so there's not necessarily a precedent on view types

[tribal yew]

This is a long list

[spark helm]

btw @tribal yew, will the proposal also add a conversion from/to basic_string?

didn't see it upon first glance

[waxen marlin]

like a constructor in std::string?

[spark helm]

both

like with string_view

a basic_string does store a C string after all

[waxen marlin]

looks like that is intended

https://github.com/jeremy-rifkin/zstring_view/blob/main/include/zstring_view.hpp#L111-L115

for string -> view

[spark helm]

ah good

[tribal yew]

basic_string has a template constructor taking a StringViewLike which zstring_view should match

[tribal yew]

I realized the conversion operators I want introduce ambiguity... shit 🙂

oh wait nvm this was already present between std::string and std::string_view

[gusty hawk]

lol

[waxen marlin]

what's the ambiguity

[tribal yew]

void foo(const char*) {}
void foo(const std::string&) {}
void foo(std::string_view) {}
void foo(std::zstring_view) {}

Most subsets of these four will have ambiguity issues

[waxen marlin]

what expression is that ambiguous with

foo("...")?

[tribal yew]

For one yes

[waxen marlin]

;compile cpp void foo(const char*); void foo(const std::string&); void foo(std::string_view); foo("...");

[lucid flicker]

Compiler Output

/opt/compiler-explorer/gcc-14.2.0/bin/../lib/gcc/x86_64-linux-gnu/14.2.0/../../../../x86_64-linux-gnu/bin/ld: /tmp/ccRBpe9v.o: in function ​`main':
<source>:9:(.text+0xa): undefined reference to ​`foo(char const*)'
collect2: error: ld returned 1 exit status
Build failed

halalaluyafail3 | c++ | x86-64 gcc 14.2 | godbolt.org

[waxen marlin]

seems to work

[tribal yew]

Remove the char* overload for this one

[shut summit]

oh yeah, note how it also picks the wrong overload in some other cases

ie

;compile

#include <string>
#include <string_view>
#include <cstdio>

// void foo(const char*) { puts("char const*"); }
void foo(const std::string&) { puts("std::string const&");}
void foo(std::string_view) { puts("std::string_view");}
void foo(bool) { puts("bool"); }

int main(){
    foo("bar");
}

[lucid flicker]

Program Output

bool

tsche | 46ms | c++ | x86-64 gcc 14.2 | godbolt.org

[shut summit]

tbh I hadn't yet realized

void foo(const std::string&);
void foo(std::string_view);

is ambiguous when passed a string literal. It's not exactly surprising but oh well

doesn't really seem all that avoidable

[waxen marlin]

;compile cpp #include<string> #include<iostream> #include<string_view> template<int=0>void foo(const std::string&){ std::cout<<"A\n"; } void foo(std::string_view){ std::cout<<"B\n"; } int main(){ foo("..."); }

[lucid flicker]

Program Output

B

halalaluyafail3 | 46ms | c++ | x86-64 gcc 14.2 | godbolt.org

[waxen marlin]

does this count

[gusty hawk]

huh!

[waxen marlin]

what are you confused by here

[gusty hawk]

not confused

neat trick

[waxen marlin]

templates get a worse ranking compared to non-templates

if you need further ordering you can do fun stuff like requires true

[gusty hawk]

i might use this

[shut summit]

No

[wheat bay]

I'd totally use this if this was in some namespace other than std, and compiled with Clang without warnings 😛

I need one for my project...

Have you thought about making this a full library?

[waxen marlin]

isn't the warnings just about the literals being standard reserved

#pragma GCC diagnostic ignored "-Wreserved-user-defined-literal"
#pragma GCC diagnostic ignored "-Wuser-defined-literals"```instead of```cpp
#pragma GCC diagnostic ignored "-Wliteral-suffix"```seems to work for clang

[wheat bay]

Yeah, but I have to go in and fix the pragmas and the namespace, and I was looking for something I can use as is

[tribal yew]

I can do so, though it is pretty minimal 🙂

[tribal yew]

Pr welcome to fix the warnings 🫠

[wheat bay]

I figured I'd make my own, took an ~hour: https://github.com/HolyBlackCat/zstring_view/blob/master/include/em/zstring_view.h

[tribal yew]

https://isocpp.org/files/papers/P3655R0.html should be out later today

[spark helm]

you should've done a #polls for the name 😛

[tribal yew]

But are polls normative

[spark helm]

they should be

motion to formally recognize the supreme authority of TCCPP community opinion polls.

[waxen marlin]

"C++14 added std::string_view to that set" wasn't string_view C++17?

[spark helm]

indeed

[tribal yew]

Indeed

Fortunately I didn’t write that sentence

[waxen marlin]

also 6.3.1 says there are two substr functions, but I don't see that in the example implementation or 11.1.2.1

seems kind of strange to have s.substr(1) and s.substr(1,1) return different types if that is the intent though

[tribal yew]

good catch

and yes, it is strange but it's the only way

Unless we want to force users to std::string_view(zsv).substr(...)

[waxen marlin]

how about just making both versions return string_view?

[tribal yew]

The whole point of this paper is not losing type info though

[sacred rock]

would love std::string to have view() and zview() functions

i think there was proposal for std::string::view but can't remember how far it made

oh its almost in c++26. LWG pending
https://github.com/cplusplus/papers/issues/1737

considering this is almost in c++26, I'd add zsubview() too

[sacred rock]

I thought this type made some magic to allow cutting and still have a null terminator, ofcourse not the case. only possible way to do this is copy the string to another buffer :(

[tribal yew]

subzview would be weird because the view has the be only at the end of the string