On 03/07/2019 20:40, Lyberta wrote:
> JeanHeyd Meneide:
>> Finally, I have one more... thing? It's not really a concern or a nit
>> with the paper, just a bit of sadness: had we standardized a c_string_view
>> of some form, we wouldn't need what will probably amount of "*Expects:
>> *ptr[size]
>> == 0 is true" on all the specifications on the constructors for the string
>> view / charX + pointer overloads. I agree with the reasoning in the paper
>> that there is rarely a case where users expect that to be the case, but
>> it's not exactly impossible: I have received a lovely crop of bug reports
>> from people seeing "std::string_view" overloads in my libraries and passing
>> non-null-terminated strings into them, because that's what string_view
>> promises. Whether or not your wording has an "expects" clause, it's not
>> difficult or hard to imagine substring or other similar pointer + size
>> manipulations to produce hell here.
>>
>> Then again, this is marked as the *path*_view type. Maybe that will
>> be enough visual indication to the user they should think carefully and not
>> just toss in random substrings. I certainly hope it is.
>
> Since std::c_string_view would not own the string, how do you enforce
> the null terminator because the user can mutate the buffer. Do you check
> manually in every member function and assert?

For a c_string_view, I would expect that one would have to do as
path_view does, and require immutability. This is one of the major
reasons why I don't find a c_string_view compelling, personally.

Niall