------=_Part_345_883022954.1547131851607
Content-Type: multipart/alternative;
 boundary="----=_Part_346_965538646.1547131851607"

------=_Part_346_965538646.1547131851607
Content-Type: text/plain; charset="UTF-8"

The design of the type is wrong. It's a NUL-terminated string, so it should
act like a NUL-terminated string. Namely, it should not have a *size*.
`cstring_view<CharT>` should only store a `CharT*`. Users of NUL-terminated
strings, pretty much universally, do not need the length of the string.
With your way, if I have a NUL-terminated `const char*`, constructing a
`cstring_view` is an O(n) operation, since it has to find the length. Even
though I will *never use it*.

So let's not do pointless work.

The end iterator should be a sentinel type that can compare to any
`CharT*`, such that if the pointed-to value is NUL, it compares equal. Note
that this sentinel should be a stand-alone class, so other users may use it
for their own range needs. That is, you could do
`range::for_each(some_char_array, std::null_terminated, ...)`.

And yes, this means that you have to remove some of `string_view`'s
interfaces (any reverse or search from the end operations). People who use
NUL-terminated strings don't want to do that.

With such a design, and the C++20 ranges, the type will still be a
ContiguousRange, but it will not be a SizedRange.

--
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/b8c5c661-26b3-4bc5-b194-296f05b0da11%40isocpp.org.

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

<div dir=3D"ltr"><div>The design of the type is wrong. It&#39;s a NUL-termi=
nated string, so it should act like a NUL-terminated string. Namely, it sho=
uld not have a <i>size</i>. `cstring_view&lt;CharT&gt;` should only store a=
 `CharT*`. Users of NUL-terminated strings, pretty much universally, do not=
 need the length of the string. With your way, if I have a NUL-terminated `=
const char*`, constructing a `cstring_view` is an O(n) operation, since it =
has to find the length. Even though I will <i>never use it</i>.</div><div><=
br></div><div>So let&#39;s not do pointless work.<br></div><div><br></div><=
div>The end iterator should be a sentinel type that can compare to any `Cha=
rT*`, such that if the pointed-to value is NUL, it compares equal. Note tha=
t this sentinel should be a stand-alone class, so other users may use it fo=
r their own range needs. That is, you could do `range::for_each(some_char_a=
rray, std::null_terminated, ...)`.</div><div><br></div><div>And yes, this m=
eans that you have to remove some of `string_view`&#39;s interfaces (any re=
verse or search from the end operations). People who use NUL-terminated str=
ings don&#39;t want to do that.<br></div><div><br></div><div>With such a de=
sign, and the C++20 ranges, the type will still be a ContiguousRange, but i=
t will not be a SizedRange.</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/b8c5c661-26b3-4bc5-b194-296f05b0da11%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b8c5c661-26b3-4bc5-b194-296f05b0da11=
%40isocpp.org</a>.<br />

------=_Part_346_965538646.1547131851607--

------=_Part_345_883022954.1547131851607--

.

------=_Part_409_606915393.1547132529648
Content-Type: multipart/alternative;
 boundary="----=_Part_410_2106476880.1547132529649"

------=_Part_410_2106476880.1547132529649
Content-Type: text/plain; charset="UTF-8"

On Thursday, January 10, 2019 at 9:50:51 AM UTC-5, Nicol Bolas wrote:
>
> The design of the type is wrong. It's a NUL-terminated string, so it
> should act like a NUL-terminated string. Namely, it should not have a
> *size*. `cstring_view<CharT>` should only store a `CharT*`. Users of
> NUL-terminated strings, pretty much universally, do not need the length of
> the string. With your way, if I have a NUL-terminated `const char*`,
> constructing a `cstring_view` is an O(n) operation, since it has to find
> the length. Even though I will *never use it*.
>
> So let's not do pointless work.
>

To add to this, if you have a sized string (`std::string` or
`std::string_view`) with embedded NUL characters, and convert it to a
`cstring_view`, what will be the `size` of that string? The size ought to
be such that the `end` iterator points to the first NUL character. But the
naive implementation won't do this; it will just take the size from the
given string, which is wrong.

And making this work correctly is an O(n) operation to compute the proper
size. Which is a property the user again *does not need*. NUL-terminated
strings are not sized strings and should not look like they are. And if the
user needs to turn it into a sized string... there can be an explicit
conversion to `string_view` for that purpose.

We want this type to be able to replace every occurrence of the use of a
NUL-terminated `const char*`. People are going to be a bit hesitant to do
so if constructing it is O(n).

--
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/3276bce7-d9e0-421c-869e-eb83402744a7%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 10, 2019 at 9:50:51 AM UTC-5, Nicol B=
olas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv>The design of the type is wrong. It&#39;s a NUL-terminated string, so it=
 should act like a NUL-terminated string. Namely, it should not have a <i>s=
ize</i>. `cstring_view&lt;CharT&gt;` should only store a `CharT*`. Users of=
 NUL-terminated strings, pretty much universally, do not need the length of=
 the string. With your way, if I have a NUL-terminated `const char*`, const=
ructing a `cstring_view` is an O(n) operation, since it has to find the len=
gth. Even though I will <i>never use it</i>.</div><div><br></div><div>So le=
t&#39;s not do pointless work.<br></div></div></blockquote><div><br></div><=
div>To add to this, if you have a sized string (`std::string` or `std::stri=
ng_view`) with embedded NUL characters, and convert it to a `cstring_view`,=
 what will be the `size` of that string? The size ought to be such that the=
 `end` iterator points to the first NUL character. But the naive implementa=
tion won&#39;t do this; it will just take the size from the given string, w=
hich is wrong.<br></div><div><br></div><div>And making this work correctly =
is an O(n) operation to compute the proper size. Which is a property the us=
er again <i>does not need</i>. NUL-terminated strings are not sized strings=
 and should not look like they are. And if the user needs to turn it into a=
 sized string... there can be an explicit conversion to `string_view` for t=
hat purpose.<br></div><div><br></div><div>We want this type to be able to r=
eplace every occurrence of the use of a NUL-terminated `const char*`. Peopl=
e are going to be a bit hesitant to do so if constructing it is O(n).<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/3276bce7-d9e0-421c-869e-eb83402744a7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3276bce7-d9e0-421c-869e-eb83402744a7=
%40isocpp.org</a>.<br />

------=_Part_410_2106476880.1547132529649--

------=_Part_409_606915393.1547132529648--

.

--00000000000097e4b4057f330f90
Content-Type: text/plain; charset="UTF-8"

On Thursday, January 10, 2019 at 9:50:51 AM UTC-5, Nicol Bolas wrote:
> The design of the type is wrong. It's a NUL-terminated string, so it
should act like a NUL-terminated string. Namely, it should not have a size.
`cstring_view<CharT>` should only store a `CharT*`. Users of NUL-terminated
strings, pretty much universally, do not need the length of the string.
With your way, if I have a NUL-terminated `const char*`, constructing a
`cstring_view` is an O(n) operation, since it has to find the length. Even
though I will never use it.

Thanks for your feedback Nicol.

I did consider designing it the way you suggest (just storing the pointer
and not the size) and chose to go with storing the size.  The rationale
behind this design decision clearly should be added to the paper.

I do not think it's the case that people do not need the size of
null-terminated strings.  This is proven pretty easily with a github search
for strlen.  There are 110 million calls to strlen.  I think we can
convince ourselves that most of those calls are from people that want the
size of a null-terminated string.

It is not correct that constructing a cstring_view is commonly a O(n)
operation.  The copy constructor is constrant time.  The conversion from
std::string to std::cstring_view is constant time.  Calculating the size
may take place at compile-time, as is the case for conversion from a string
literal, or some other constexpr source. Even, in the case of constructing
it from some other source at runtime, you may be able to use the
{std::null_terminated, ptr,size} constructor, if you already know the size
and that's it's null-terminated.  The only case where strlen is called is
if it takes place is from a const char* returned from (say) a C callback or
the like.  In such cases it is called once.  Now, in the case where you are
simply forwarding from a C callback to some C function, and that is the
only thing you do with it, yes it would be more efficient to not call
strlen - but in such cases, I think you can just leave the type as const
char*, none of the rationale in "Why not use const char*?" really applies
here.

Even if we ignore that, and say the decision here is between calling strlen
once speculatively, or zero or more times on-demand.  Which is overall more
efficient depends on whether the average of the on-demand case is higher
than 1.  I am aware of evidence that adoption of string_view cut down
measurably on calls to strlen, so I believe it is the case that the average
of the on-demand case is higher than 1.

Furthermore there are security improvements from storing and passing the
size.

So on the whole I think storing the size is the better of the two choices.

In regards to your question about embedded NUL characters (and this should
also be better explained and specified in the proposal), the intention is
that the null-terminated class invariant is defined as, roughly speaking,
`strlen(sv_.data()) == sv_.size()` has both defined behaviour and is true.
This class invariant is therefore intended to be a requires of every
constructor, and has the standard disposition of any constraint.  (That is,
if it is false, behaviour is undefined.  It's up to the implementation and
compilation configuration whether to expensively diagnose constraints or
assume they are true - ie debug vs optimized builds etc).

So, yes, `strlen(sv_.data()) == sv_.size()` implies that embedded NULs are
a constraint violation, with the usual consequences.  In an unchecked
constraint mode I expect the practical consequences to be the same as
embedded NULs in some std::string s.  That being that strlen(s.c_str())
does not equal s.size().

--
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%2B4KHJAqzb95XUrkVJXdrZ1GbPf1bBMS-p_xmZPt3XHseCS5w%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>On Thursd=
ay, January 10, 2019 at 9:50:51 AM UTC-5, Nicol Bolas wrote:</div><div>&gt;=
 The design of the type is wrong. It&#39;s a NUL-terminated string, so it s=
hould act like a NUL-terminated string. Namely, it should not have a size. =
`cstring_view&lt;CharT&gt;` should only store a `CharT*`. Users of NUL-term=
inated strings, pretty much universally, do not need the length of the stri=
ng. With your way, if I have a NUL-terminated `const char*`, constructing a=
 `cstring_view` is an O(n) operation, since it has to find the length. Even=
 though I will never use it.</div><div>=C2=A0</div><div>Thanks for your fee=
dback Nicol.</div><div><br></div><div>I did consider designing it the way y=
ou suggest (just storing the pointer and not the size) and chose to go with=
 storing the size.=C2=A0 The rationale behind this design decision clearly =
should be added to the paper.</div><div><br></div><div>I do not think it&#3=
9;s the case that people do not need the size of null-terminated strings.=
=C2=A0 This is proven pretty easily with a github search for strlen.=C2=A0 =
There are 110 million calls to strlen.=C2=A0 I think we can convince oursel=
ves that most of those calls are from people that want the size of a null-t=
erminated string.</div><div><br></div><div>It is not correct that construct=
ing a cstring_view is commonly a O(n) operation.=C2=A0 The copy constructor=
 is constrant time.=C2=A0 The conversion from std::string to std::cstring_v=
iew is constant time.=C2=A0 Calculating the size may take place at compile-=
time, as is the case for conversion from a string literal, or some other co=
nstexpr source. Even, in the case of constructing it from some other source=
 at runtime, you may be able to use the {std::null_terminated, ptr,size} co=
nstructor, if you already know the size and that&#39;s it&#39;s null-termin=
ated.=C2=A0 The only case where strlen is called is if it takes place is fr=
om a const char* returned from (say) a C callback or the like.=C2=A0 In suc=
h cases it is called once.=C2=A0 Now, in the case where you are simply forw=
arding from a C callback to some C function, and that is the only thing you=
 do with it, yes it would be more efficient to not call strlen - but in suc=
h cases, I think you can just leave the type as const char*, none of the ra=
tionale in &quot;Why not use const char*?&quot; really applies here.</div><=
div><br></div><div>Even if we ignore that, and say the decision here is bet=
ween calling strlen once speculatively, or zero or more times on-demand.=C2=
=A0 Which is overall more efficient depends on whether the average of the o=
n-demand case is higher than 1.=C2=A0 I am aware of evidence that adoption =
of string_view cut down measurably on calls to strlen, so I believe it is t=
he case that the average of the on-demand case is higher than 1.</div><div>=
<br></div><div>Furthermore there are security improvements from storing and=
 passing the size.</div><div><br></div><div>So on the whole I think storing=
 the size is the better of the two choices.</div><div><br></div><div>In reg=
ards to your question about embedded NUL characters (and this should also b=
e better explained and specified in the proposal), the intention is that th=
e null-terminated class invariant is defined as, roughly speaking, `strlen(=
sv_.data()) =3D=3D sv_.size()` has both defined behaviour and is true.=C2=
=A0 This class invariant is therefore intended to be a requires of every co=
nstructor, and has the standard disposition of any constraint.=C2=A0 (That =
is, if it is false, behaviour is undefined.=C2=A0 It&#39;s up to the implem=
entation and compilation configuration whether to expensively diagnose cons=
traints or assume they are true - ie debug vs optimized builds etc).</div><=
div><br></div><div>So, yes, `strlen(sv_.data()) =3D=3D sv_.size()` implies =
that embedded NULs are a constraint violation, with the usual consequences.=
=C2=A0 In an unchecked constraint mode I expect the practical consequences =
to be the same as embedded NULs in some std::string s.=C2=A0 That being tha=
t strlen(s.c_str()) does not equal s.size().</div><div>=C2=A0</div></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/CAB%2B4KHJAqzb95XUrkVJXdrZ1GbPf1bBMS-=
p_xmZPt3XHseCS5w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHJAqzb9=
5XUrkVJXdrZ1GbPf1bBMS-p_xmZPt3XHseCS5w%40mail.gmail.com</a>.<br />

--00000000000097e4b4057f330f90--

.

> I do not think it's the case that people do not need the size of null-ter=
minated strings.

There are plenty of cases where the size is not needed, e.g. parsing a
string where you can use NUL as a sentinel and don't need the size.
Always computing the size would be a big pessimization. There is also
a small cost from an extra data member but from my benchmarks in {fmt}
when I switched from null-terminated strings to string_view it was
tolerable.

- Victor

On Fri, Jan 11, 2019 at 1:42 PM Andrew Tomazos <andrewtomazos@gmail.com> wr=
ote:
>
> On Thursday, January 10, 2019 at 9:50:51 AM UTC-5, Nicol Bolas wrote:
> > The design of the type is wrong. It's a NUL-terminated string, so it sh=
ould act like a NUL-terminated string. Namely, it should not have a size. `=
cstring_view<CharT>` should only store a `CharT*`. Users of NUL-terminated =
strings, pretty much universally, do not need the length of the string. Wit=
h your way, if I have a NUL-terminated `const char*`, constructing a `cstri=
ng_view` is an O(n) operation, since it has to find the length. Even though=
 I will never use it.
>
> Thanks for your feedback Nicol.
>
> I did consider designing it the way you suggest (just storing the pointer=
 and not the size) and chose to go with storing the size.  The rationale be=
hind this design decision clearly should be added to the paper.
>
> I do not think it's the case that people do not need the size of null-ter=
minated strings.  This is proven pretty easily with a github search for str=
len.  There are 110 million calls to strlen.  I think we can convince ourse=
lves that most of those calls are from people that want the size of a null-=
terminated string.
>
> It is not correct that constructing a cstring_view is commonly a O(n) ope=
ration.  The copy constructor is constrant time.  The conversion from std::=
string to std::cstring_view is constant time.  Calculating the size may tak=
e place at compile-time, as is the case for conversion from a string litera=
l, or some other constexpr source. Even, in the case of constructing it fro=
m some other source at runtime, you may be able to use the {std::null_termi=
nated, ptr,size} constructor, if you already know the size and that's it's =
null-terminated.  The only case where strlen is called is if it takes place=
 is from a const char* returned from (say) a C callback or the like.  In su=
ch cases it is called once.  Now, in the case where you are simply forwardi=
ng from a C callback to some C function, and that is the only thing you do =
with it, yes it would be more efficient to not call strlen - but in such ca=
ses, I think you can just leave the type as const char*, none of the ration=
ale in "Why not use const char*?" really applies here.
>
> Even if we ignore that, and say the decision here is between calling strl=
en once speculatively, or zero or more times on-demand.  Which is overall m=
ore efficient depends on whether the average of the on-demand case is highe=
r than 1.  I am aware of evidence that adoption of string_view cut down mea=
surably on calls to strlen, so I believe it is the case that the average of=
 the on-demand case is higher than 1.
>
> Furthermore there are security improvements from storing and passing the =
size.
>
> So on the whole I think storing the size is the better of the two choices=
..
>
> In regards to your question about embedded NUL characters (and this shoul=
d also be better explained and specified in the proposal), the intention is=
 that the null-terminated class invariant is defined as, roughly speaking, =
`strlen(sv_.data()) =3D=3D sv_.size()` has both defined behaviour and is tr=
ue.  This class invariant is therefore intended to be a requires of every c=
onstructor, and has the standard disposition of any constraint.  (That is, =
if it is false, behaviour is undefined.  It's up to the implementation and =
compilation configuration whether to expensively diagnose constraints or as=
sume they are true - ie debug vs optimized builds etc).
>
> So, yes, `strlen(sv_.data()) =3D=3D sv_.size()` implies that embedded NUL=
s are a constraint violation, with the usual consequences.  In an unchecked=
 constraint mode I expect the practical consequences to be the same as embe=
dded NULs in some std::string s.  That being that strlen(s.c_str()) does no=
t equal s.size().
>
>
> --
> 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/isoc=
pp.org/d/msgid/std-proposals/CAB%2B4KHJAqzb95XUrkVJXdrZ1GbPf1bBMS-p_xmZPt3X=
HseCS5w%40mail.gmail.com.

--=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/CANawtxb%2B10M0jzp5JfaqTQhGafWPKOE-YKfzMA7b9bYqT=
goq1Q%40mail.gmail.com.

.

------=_Part_974_950856669.1547235680583
Content-Type: multipart/alternative;
 boundary="----=_Part_975_101417975.1547235680583"

------=_Part_975_101417975.1547235680583
Content-Type: text/plain; charset="UTF-8"


My feeling boils down to this:

`cstring_view` exists for the principle purpose of making `const char*`
values for the purpose of a NUL-terminated string *obsolete*. Users should
be able to convert any C++ APIs from `const char*` to `cstring_view` with
no overhead relative to `const char*`, in runtime performance or memory
overhead. *Ever*.

A sentinel-based `cstring_view` can do that; a size-based `cstring_view`
*cannot*. Your design may improve performance in some use cases, but this
comes at a cost in memory overhead to *everyone*, whether they want it or
not. As well as a cost in cases where such a size goes unused but must be
calculated.

As such, there will be times where a `const char*` is the better
alternative. And if there exists such a case, then it is my opinion that
such a `cstring_view` design has *failed* at its primary objective.

--
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/fd1c15c2-e293-4448-a7c2-ca2b73ce2147%40isocpp.org.

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

<div dir=3D"ltr"><div></div><div>My feeling boils down to this:</div><div><=
br></div><div>`cstring_view` exists for the principle purpose of making `co=
nst char*` values for the purpose of a NUL-terminated string <i>obsolete</i=
>. Users should be able to convert any C++ APIs from `const char*` to `cstr=
ing_view` with no overhead relative to `const char*`, in runtime performanc=
e or memory overhead. <i>Ever</i>.<br></div><div><br></div><div>A sentinel-=
based `cstring_view` can do that; a size-based `cstring_view` <i>cannot</i>=
.. Your design may improve performance in some use cases, but this comes at =
a cost in memory overhead to <i>everyone</i>, whether they want it or not. =
As well as a cost in cases where such a size goes unused but must be calcul=
ated.</div><div><br></div><div>As such, there will be times where a `const =
char*` is the better alternative. And if there exists such a case, then it =
is my opinion that such a `cstring_view` design has <i>failed</i> at its pr=
imary objective.</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/fd1c15c2-e293-4448-a7c2-ca2b73ce2147%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fd1c15c2-e293-4448-a7c2-ca2b73ce2147=
%40isocpp.org</a>.<br />

------=_Part_975_101417975.1547235680583--

------=_Part_974_950856669.1547235680583--

.

------=_Part_1040_1883247046.1547246174869
Content-Type: text/plain; charset="UTF-8"

How about calculating the length on demand. This costs an if in size() but should be the most efficient way overall as only the const char* ctor would leave the size unknown.

--
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/64625544-db80-4d6d-9808-e80d9947111f%40isocpp.org.

------=_Part_1040_1883247046.1547246174869--

.