--000000000000e601ea057ec83ff1
Content-Type: text/plain; charset="UTF-8"

A big problem we're seeing with std::string_view in practice is at the
interface with C libraries and APIs.  Because string literals and
std::string are null-terminated they can be passed as const char* (either
with array-to-pointer standard conversion or with .cstr()) without heap
allocation and without copy into a new std::string.

However when you have a std::string_view, even if it is a view of a string
literal or entire std::string, as it commonly is, you need to heap allocate
and copy into a new std::string for the null terminator.

Because of this we are seeing recommendations to avoid std::string_view as
a replacement for const std::string&.  Even if this means paying up front
for the conversion from a string literal to a std::string - if the origin
is a computed std::string, it is still cheaper.

For this reason I am considering proposing a std::cstr_view class that is
like std::string_view, but also requires null-termination of the subject
text.

Perhaps std::basic_cstr_view could be a subclass of std::basic_string_view,
and setup in the obvious way such that it is only constructible from const
char* or std::string.  A std::cstr_view is a std::string_view, but not visa
versa.  It would extend std::string_view with a .cstr() member function.

Thoughts?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BXdqQvhSgNfLCuMP3cRLokX72AsMfcuFUnqe%3Dpd%2BVdmw%40mail.gmail.com.

--000000000000e601ea057ec83ff1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A big problem we&#39;re seeing with std::string_view in pr=
actice is at the interface with C libraries and APIs.=C2=A0 Because string =
literals and std::string are null-terminated they can be passed as const ch=
ar* (either with array-to-pointer standard conversion or with .cstr()) with=
out heap allocation and without copy into a new std::string.<div><br></div>=
<div>However when you have a std::string_view, even if it is a view of a st=
ring literal or entire std::string, as it commonly is, you need to heap all=
ocate and copy into a new std::string for the null terminator.<div><br></di=
v><div>Because of this we are seeing recommendations to avoid std::string_v=
iew as a replacement for const std::string&amp;.=C2=A0 Even if this means p=
aying up front for the conversion from a string literal to a std::string - =
if the origin is a computed std::string, it is still cheaper.</div><div><br=
></div><div>For this reason I am considering proposing a std::cstr_view cla=
ss that is like std::string_view, but also requires null-termination of the=
 subject text.</div></div><div><br></div><div>Perhaps std::basic_cstr_view =
could be a subclass of std::basic_string_view, and setup in the obvious way=
 such that it is only constructible from const char* or std::string.=C2=A0 =
A std::cstr_view is a std::string_view, but not visa versa.=C2=A0 It would =
extend std::string_view with a .cstr() member function.</div><div><br></div=
><div>Thoughts?</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BXdqQvhSgNfLCuMP3cRLokX72A=
sMfcuFUnqe%3Dpd%2BVdmw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH=
%2BXdqQvhSgNfLCuMP3cRLokX72AsMfcuFUnqe%3Dpd%2BVdmw%40mail.gmail.com</a>.<br=
 />

--000000000000e601ea057ec83ff1--

.

--000000000000c568ab057ecc7023
Content-Type: text/plain; charset="UTF-8"

On Sun, Jan 6, 2019, 12:16 PM Andrew Tomazos <andrewtomazos@gmail.com wrote:

> A big problem we're seeing with std::string_view in practice is at the
> interface with C libraries and APIs.  Because string literals and
> std::string are null-terminated they can be passed as const char* (either
> with array-to-pointer standard conversion or with .cstr()) without heap
> allocation and without copy into a new std::string.
>
> However when you have a std::string_view, even if it is a view of a string
> literal or entire std::string, as it commonly is, you need to heap allocate
> and copy into a new std::string for the null terminator.
>

You only need to do that if you can't guarantee they you have a
null-terminated string. If you do, you can use std::string_view::data().


> Because of this we are seeing recommendations to avoid std::string_view as
> a replacement for const std::string&.  Even if this means paying up front
> for the conversion from a string literal to a std::string - if the origin
> is a computed std::string, it is still cheaper.
>
> For this reason I am considering proposing a std::cstr_view class that is
> like std::string_view, but also requires null-termination of the subject
> text.
>
> Perhaps std::basic_cstr_view could be a subclass of
> std::basic_string_view, and setup in the obvious way such that it is only
> constructible from const char* or std::string.  A std::cstr_view is a
> std::string_view, but not visa versa.  It would extend std::string_view
> with a .cstr() member function.
>
> Thoughts?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BXdqQvhSgNfLCuMP3cRLokX72AsMfcuFUnqe%3Dpd%2BVdmw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BXdqQvhSgNfLCuMP3cRLokX72AsMfcuFUnqe%3Dpd%2BVdmw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2fXSRHTVGQdcZXXVS9MVgnTufK1BwYZK-XD0x4T2iABQ%40mail.gmail.com.

--000000000000c568ab057ecc7023
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, =
Jan 6, 2019, 12:16 PM Andrew Tomazos &lt;<a href=3D"mailto:andrewtomazos@gm=
ail.com">andrewtomazos@gmail.com</a> wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">A big problem we&#39;re seeing with std::string_v=
iew in practice is at the interface with C libraries and APIs.=C2=A0 Becaus=
e string literals and std::string are null-terminated they can be passed as=
 const char* (either with array-to-pointer standard conversion or with .cst=
r()) without heap allocation and without copy into a new std::string.<div><=
br></div><div>However when you have a std::string_view, even if it is a vie=
w of a string literal or entire std::string, as it commonly is, you need to=
 heap allocate and copy into a new std::string for the null terminator.</di=
v></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">You only need to do that if you can&#39;t guarantee they you have a nul=
l-terminated string. If you do, you can use std::string_view::data().</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br></div><div>Beca=
use of this we are seeing recommendations to avoid std::string_view as a re=
placement for const std::string&amp;.=C2=A0 Even if this means paying up fr=
ont for the conversion from a string literal to a std::string - if the orig=
in is a computed std::string, it is still cheaper.</div><div><br></div><div=
>For this reason I am considering proposing a std::cstr_view class that is =
like std::string_view, but also requires null-termination of the subject te=
xt.</div></div><div><br></div><div>Perhaps std::basic_cstr_view could be a =
subclass of std::basic_string_view, and setup in the obvious way such that =
it is only constructible from const char* or std::string.=C2=A0 A std::cstr=
_view is a std::string_view, but not visa versa.=C2=A0 It would extend std:=
:string_view with a .cstr() member function.</div><div><br></div><div>Thoug=
hts?</div><div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BXdqQvhSgNfLCuMP3cRLokX72A=
sMfcuFUnqe%3Dpd%2BVdmw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a=
/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BXdqQvhSgNfLCuMP3cRLokX72AsMfc=
uFUnqe%3Dpd%2BVdmw%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq2fXSRHTVGQdcZXXVS9MVgnTufK1BwY=
ZK-XD0x4T2iABQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2fXSRHTVGQ=
dcZXXVS9MVgnTufK1BwYZK-XD0x4T2iABQ%40mail.gmail.com</a>.<br />

--000000000000c568ab057ecc7023--

.

--0000000000001f71e8057ecd56f9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 6, 2019 at 6:16 AM Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> A big problem we're seeing with std::string_view in practice is at the
> interface with C libraries and APIs.  Because string literals and
> std::string are null-terminated they can be passed as const char* (either
> with array-to-pointer standard conversion or with .cstr()) without heap
> allocation and without copy into a new std::string.
>
> However when you have a std::string_view, even if it is a view of a strin=
g
> literal or entire std::string, as it commonly is, you need to heap alloca=
te
> and copy into a new std::string for the null terminator.
>
> Because of this we are seeing recommendations to avoid std::string_view a=
s
> a replacement for const std::string&.  Even if this means paying up front
> for the conversion from a string literal to a std::string - if the origin
> is a computed std::string, it is still cheaper.
>
> For this reason I am considering proposing a std::cstr_view class that is
> like std::string_view, but also requires null-termination of the subject
> text.
>
> Perhaps std::basic_cstr_view could be a subclass of
> std::basic_string_view, and setup in the obvious way such that it is only
> constructible from const char* or std::string.  A std::cstr_view is a
> std::string_view, but not visa versa.  It would extend std::string_view
> with a .cstr() member function.
>
> Thoughts?
>

If you're looking to pass around cstrings, why not use const char* (and
optionally a size_t)?  As bugprone as it may be, the intent is very clear
and there's no behind the scenes magic required.  Wherever you might want
to use a cstring with c++ functions that accept string_view, you can always
create a temporary string_view.  Otherwise, a simple wrapper type can make
it very difficult to end up with a non null terminated string_view:

class cstring_view {
  public:
    cstring_view(const char *s) : sv_{s} {}
    cstring_view(const std::string &s) : sv_{s} {}
    const std::string_view &view() { return sv_; };
  private:
    std::string_view sv_;
};

>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2B=
XdqQvhSgNfLCuMP3cRLokX72AsMfcuFUnqe%3Dpd%2BVdmw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2=
BXdqQvhSgNfLCuMP3cRLokX72AsMfcuFUnqe%3Dpd%2BVdmw%40mail.gmail.com?utm_mediu=
m=3Demail&utm_source=3Dfooter>
> .
>
=E1=90=A7

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CACCCiPo32QOmi70GjRimdyf4pwg1-_UHiQnFwQ6UwdsWR%3=
D-zpQ%40mail.gmail.com.

--0000000000001f71e8057ecd56f9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Sun, Jan 6, 2019 at 6:16 AM Andrew Tom=
azos &lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andre=
wtomazos@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr">A big problem we&#39;re seeing with std:=
:string_view in practice is at the interface with C libraries and APIs.=C2=
=A0 Because string literals and std::string are null-terminated they can be=
 passed as const char* (either with array-to-pointer standard conversion or=
 with .cstr()) without heap allocation and without copy into a new std::str=
ing.<div><br></div><div>However when you have a std::string_view, even if i=
t is a view of a string literal or entire std::string, as it commonly is, y=
ou need to heap allocate and copy into a new std::string for the null termi=
nator.<div><br></div><div>Because of this we are seeing recommendations to =
avoid std::string_view as a replacement for const std::string&amp;.=C2=A0 E=
ven if this means paying up front for the conversion from a string literal =
to a std::string - if the origin is a computed std::string, it is still che=
aper.</div><div><br></div><div>For this reason I am considering proposing a=
 std::cstr_view class that is like std::string_view, but also requires null=
-termination of the subject text.</div></div><div><br></div><div>Perhaps st=
d::basic_cstr_view could be a subclass of std::basic_string_view, and setup=
 in the obvious way such that it is only constructible from const char* or =
std::string.=C2=A0 A std::cstr_view is a std::string_view, but not visa ver=
sa.=C2=A0 It would extend std::string_view with a .cstr() member function.<=
/div><div><br></div><div>Thoughts?</div></div></blockquote><div><br></div><=
div>If you&#39;re looking to pass around cstrings, why not use const char* =
(and optionally a size_t)?=C2=A0 As bugprone as it may be, the intent is ve=
ry clear and there&#39;s no behind the scenes magic required.=C2=A0 Whereve=
r you might want to use a cstring with c++ functions that accept string_vie=
w, you can always create a temporary string_view.=C2=A0 Otherwise, a simple=
 wrapper type can make it very difficult to end up with a non null terminat=
ed string_view:<br></div><div><br></div><div><div>class cstring_view {</div=
><div>=C2=A0 public:</div><div>=C2=A0 =C2=A0 cstring_view(const char *s) : =
sv_{s} {}</div><div>=C2=A0 =C2=A0 cstring_view(const std::string &amp;s) : =
sv_{s} {}</div><div>=C2=A0 =C2=A0 const std::string_view &amp;view() { retu=
rn sv_; };</div><div>=C2=A0 private:</div><div>=C2=A0 =C2=A0 std::string_vi=
ew sv_;</div><div>};</div></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BXdqQvhSgNfLCuMP3cRLokX72A=
sMfcuFUnqe%3Dpd%2BVdmw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CAB%2B4KH%2BXdqQvhSgNfLCuMP3cRLokX72AsMfcuFUnqe%3Dpd%2BVdmw%=
40mail.gmail.com</a>.<br>
</blockquote></div></div></div><div hspace=3D"streak-pt-mark" style=3D"max-=
height:1px"><img alt=3D"" style=3D"width:0px;max-height:0px;overflow:hidden=
" src=3D"https://mailfoogae.appspot.com/t?sender=3Dad2lsbEBqYWdlbHMudXM%3D&=
amp;type=3Dzerocontent&amp;guid=3D68dbcd98-f5c3-4e27-a0b0-84b3554f7aa8"><fo=
nt color=3D"#ffffff" size=3D"1">=E1=90=A7</font></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACCCiPo32QOmi70GjRimdyf4pwg1-_UHiQnF=
wQ6UwdsWR%3D-zpQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACCCiPo32QOmi7=
0GjRimdyf4pwg1-_UHiQnFwQ6UwdsWR%3D-zpQ%40mail.gmail.com</a>.<br />

--0000000000001f71e8057ecd56f9--

.

------=_Part_1367_1582486696.1546795370461
Content-Type: multipart/alternative;
 boundary="----=_Part_1368_62303323.1546795370462"

------=_Part_1368_62303323.1546795370462
Content-Type: text/plain; charset="UTF-8"



On Sunday, January 6, 2019 at 11:16:55 AM UTC-5, Nicolas Lesser wrote:
>
> On Sun, Jan 6, 2019, 12:16 PM Andrew Tomazos <andrew...@gmail.com
> <javascript:> wrote:
>
>> A big problem we're seeing with std::string_view in practice is at the
>> interface with C libraries and APIs.  Because string literals and
>> std::string are null-terminated they can be passed as const char* (either
>> with array-to-pointer standard conversion or with .cstr()) without heap
>> allocation and without copy into a new std::string.
>>
>> However when you have a std::string_view, even if it is a view of a
>> string literal or entire std::string, as it commonly is, you need to heap
>> allocate and copy into a new std::string for the null terminator.
>>
>
> You only need to do that if you can't guarantee they you have a
> null-terminated string. If you do, you can use std::string_view::data().
>

How exactly would you do that? The `string_view` you get from implicit
conversion from `std::string`, `char[]` literals and pretty much every
other string conversion that people write does *not* include the
NUL-terminator in the `string_view` itself. So `string_view("foo")` has a
size of 3. Checking to see if a given `string_view` is NUL-terminated
requires reading past the end of the range... which you're not really
allowed to do. And can easily invoke UB if the string is not NUL-terminated
(since that may be unallocated memory).

If a function takes a `string_view` as a parameter, it is not unreasonable
for the user to expect that *any* `string_view` would be a legitimate value
(barring a contract or other documentation). As such, if your API requires
a NUL-terminated string, it is not unreasonable to have that be directly
encoded in the type the function takes as a parameter, so that it is not
possible for a user to break that requirement.

Especially since, as previously stated, there's no way to check that from
within the function.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/63605718-e265-4264-bc9f-9065ae4e664c%40isocpp.org.

------=_Part_1368_62303323.1546795370462
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, January 6, 2019 at 11:16:55 AM UTC-5, N=
icolas Lesser wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, Jan 6, 2=
019, 12:16 PM Andrew Tomazos &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"VFDgmCjqEAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">andrew...@gmail.com</a> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">A big problem we&#39;re seeing wit=
h std::string_view in practice is at the interface with C libraries and API=
s.=C2=A0 Because string literals and std::string are null-terminated they c=
an be passed as const char* (either with array-to-pointer standard conversi=
on or with .cstr()) without heap allocation and without copy into a new std=
::string.<div><br></div><div>However when you have a std::string_view, even=
 if it is a view of a string literal or entire std::string, as it commonly =
is, you need to heap allocate and copy into a new std::string for the null =
terminator.</div></div></blockquote></div></div><div dir=3D"auto"><br></div=
><div dir=3D"auto">You only need to do that if you can&#39;t guarantee they=
 you have a null-terminated string. If you do, you can use std::string_view=
::data().</div></div></blockquote><div><br></div><div>How exactly would you=
 do that? The `string_view` you get from implicit conversion from `std::str=
ing`, `char[]` literals and pretty much every other string conversion that =
people write does <i>not</i> include the NUL-terminator in the `string_view=
` itself. So `string_view(&quot;foo&quot;)` has a size of 3. Checking to se=
e if a given `string_view` is NUL-terminated requires reading past the end =
of the range... which you&#39;re not really allowed to do. And can easily i=
nvoke UB if the string is not NUL-terminated (since that may be unallocated=
 memory).<br></div><br><div>If a function takes a `string_view` as a parame=
ter, it is not unreasonable for the user to expect that <i>any</i> `string_=
view` would be a legitimate value (barring a contract or other documentatio=
n). As such, if your API requires a NUL-terminated string, it is not unreas=
onable to have that be directly encoded in the type the function takes as a=
 parameter, so that it is not possible for a user to break that requirement=
..</div><div><br></div><div>Especially since, as previously stated, there&#3=
9;s no way to check that from within the function.<br></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/63605718-e265-4264-bc9f-9065ae4e664c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/63605718-e265-4264-bc9f-9065ae4e664c=
%40isocpp.org</a>.<br />

------=_Part_1368_62303323.1546795370462--

------=_Part_1367_1582486696.1546795370461--

.