------=_Part_7264_2084377595.1431515639141
Content-Type: multipart/alternative;
 boundary="----=_Part_7265_233505654.1431515639141"

------=_Part_7265_233505654.1431515639141
Content-Type: text/plain; charset=UTF-8

C (platform) functions / libraries usually take strings as const char*.
When a parameter in one of your functions has to be forwarded to such a
function, what should the type of the parameter be? const char*?
std::string? Both?
Disadvantage of const char* is the inability to pass std::string as is, the
caller has to use c_str(). Disadvantage of std::string is the potential
unnecessary construction if a const char* is passed. Disadvantage of both
is interface duplication.

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.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_7265_233505654.1431515639141
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">C (platform) functions / libraries usually take strings as=
 const char*. When a parameter in one of your functions has to be forwarded=
 to such a function, what should the type of the parameter be? const char*?=
 std::string? Both?<div>Disadvantage of const char* is the inability to pas=
s std::string as is, the caller has to use c_str(). Disadvantage of std::st=
ring is the potential unnecessary construction if a const char* is passed. =
Disadvantage of both is interface duplication.</div><div><br></div><div>Wou=
ld it make sense to have a zstring_view for such cases? It'd be a null-term=
inated variant of string_view. Obviously it'd be less generic then string_v=
iew but as C functions aren't going anywhere any time soon it might still b=
e handy.</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7265_233505654.1431515639141--
------=_Part_7264_2084377595.1431515639141--

.

------=_Part_7716_552948493.1431526567168
Content-Type: multipart/alternative;
 boundary="----=_Part_7717_1243581282.1431526567168"

------=_Part_7717_1243581282.1431526567168
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 13, 2015 at 7:13:59 AM UTC-4, Olaf van der Spek wrote:
>
> C (platform) functions / libraries usually take strings as const char*.
> When a parameter in one of your functions has to be forwarded to such a
> function, what should the type of the parameter be? const char*?
> std::string? Both?
> Disadvantage of const char* is the inability to pass std::string as is,
> the caller has to use c_str(). Disadvantage of std::string is the potential
> unnecessary construction if a const char* is passed. Disadvantage of both
> is interface duplication.
>
> 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.
>

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.

The only useful thing you can do with it is pass it to a C-interface. And
let's examine how useful that really is.

Let's say you're writing a function which internally needs to pass one of
its parameters to a C API that takes null-terminated strings (not all C
API's pretend that strings are null-terminated). Here are your options for
that parameter type:

* `const char *`: It works directly with any compatible type. If the user
only has a `string_view`, then they'll have to allocate memory, probably
with a `std::string`.
* `const std::string &`: It works directly with any compatible type. If the
user doesn't have a `std:string` on hand, then memory will have to be
allocated. But so long as their type can implicitly construct a
`std::string`, they don't have to see it.
* `zstring_view`: It works directly with any compatible type. If the user
only has a `string_view`, then they'll have to allocate memory, probably
with a `std::string`.

In short... it's *exactly the same* as `const char *` from the user's
perspective. It hasn't improved anything beyond not having to type
`c_str()`. I'd rather see the existing option used, rather than some new
class type.

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.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_7717_1243581282.1431526567168
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, May 13, 2015 at 7:13:59 AM UTC-4, Ol=
af van der Spek 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">C (platform) functions / libraries usually take strings as const c=
har*. When a parameter in one of your functions has to be forwarded to such=
 a function, what should the type of the parameter be? const char*? std::st=
ring? Both?<div>Disadvantage of const char* is the inability to pass std::s=
tring as is, the caller has to use c_str(). Disadvantage of std::string is =
the potential unnecessary construction if a const char* is passed. Disadvan=
tage of both is interface duplication.</div><div><br></div><div>Would it ma=
ke sense to have a zstring_view for such cases? It'd be a null-terminated v=
ariant 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.=
</div></div></blockquote><div><br>So, you want to add an entire new type, j=
ust so that you don't have to type `.c_str()` after a std::string?<br><br>E=
qually 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 ca=
n chop of leading characters, but you can't do anything more than that, sin=
ce it has to be null-terminated. You could never do Regex searches that ret=
urn `zstring_view`s. And so forth.<br><br>The only useful thing you can do =
with it is pass it to a C-interface. And let's examine how useful that real=
ly is.<br><br>Let's say you're writing a function which internally needs to=
 pass one of its parameters to a C API that takes null-terminated strings (=
not all C API's pretend that strings are null-terminated). Here are your op=
tions for that parameter type:<br><br>* `const char *`: It works directly w=
ith any compatible type. If the user only has a `string_view`, then they'll=
 have to allocate memory, probably with a `std::string`.<br>* `const std::s=
tring &amp;`: It works directly with any compatible type. If the user doesn=
't have a `std:string` on hand, then memory will have to be allocated. But =
so long as their type can implicitly construct a `std::string`, they don't =
have to see it.<br>* `zstring_view`: It works directly with any compatible =
type. If the user only has a `string_view`, then they'll have to allocate m=
emory, probably with a `std::string`.<br><br>In short... it's <i>exactly th=
e same</i> as `const char *` from the user's perspective. It hasn't improve=
d anything beyond not having to type `c_str()`. I'd rather see the existing=
 option used, rather than some new class type.<br><br>Personally, I prefer =
option 2. The user has to allocate memory, but they don't have to put it th=
ere explicitly. It happens invisibly as a temporary. Or at least, it can, d=
epending on the source type.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7717_1243581282.1431526567168--
------=_Part_7716_552948493.1431526567168--

.

--089e0149bb24a2e6520515f79511
Content-Type: text/plain; charset=UTF-8

On 13 May 2015 at 06:13, Olaf van der Spek <olafvdspek@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().
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0149bb24a2e6520515f79511
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 13 May 2015 at 06:13, Olaf van der Spek <span dir=3D"lt=
r">&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek=
@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Would=
 it make sense to have a zstring_view for such cases? It&#39;d be a null-te=
rminated variant of string_view. Obviously it&#39;d be less generic then st=
ring_view but as C functions aren&#39;t going anywhere any time soon it mig=
ht still be handy.</div></div></blockquote><div><br></div><div>I rather see=
 something like this come from experience rather than invention =C2=A0It is=
 unclear how useful it would be in practice.=C2=A0 There are also some rath=
er obvious interface questions, such as what is the result of zstring_view(=
&quot;Embedded\0Here&quot;).size().</div></div>-- <br><div class=3D"gmail_s=
ignature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt=
;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0149bb24a2e6520515f79511--

.

------=_Part_252_651779312.1431654436453
Content-Type: multipart/alternative;
 boundary="----=_Part_253_140813437.1431654436453"

------=_Part_253_140813437.1431654436453
Content-Type: text/plain; charset=UTF-8

In order to be consisty

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. This won't
matter for string literals because the compiler will optimize out the
search.




--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_253_140813437.1431654436453
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In order to be consisty<br><br>On Wednesday, May 13, 2015 =
at 10:39:56 AM UTC-4, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>&nbsp=
;what is the result of zstring_view("Embedded\0Here")<wbr>.size().</div></d=
iv></div></div></blockquote><div><br></div><div>In order to maintain invari=
ant that strlen(zs.c_str()) =3D=3D zs.length() it would have to be 8. That =
is whenever you construct a zstring_vew from a string_view the implementati=
on must scan the string for nulls. This won't matter for string literals be=
cause the compiler will optimize out the search.</div><div><br></div><div><=
br></div><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"><div=
>
</div></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_253_140813437.1431654436453--
------=_Part_252_651779312.1431654436453--

.

--089e014942045606800516162103
Content-Type: text/plain; charset=UTF-8

On 14 May 2015 at 20:47, Matthew Fioravante <fmatthew5876@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'?  Or does your zmstring_view have a *different* invariant,
which seems incredibly messy for users to deal with?

If you really want something like this standardized, put it in your code
base and get experience with what works and what doesn't.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e014942045606800516162103
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 14 May 2015 at 20:47, Matthew Fioravante <span dir=3D"l=
tr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthe=
w5876@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span c=
lass=3D"">On Wednesday, May 13, 2015 at 10:39:56 AM UTC-4, Nevin &quot;:-)&=
quot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div>=C2=A0what is the result of zstring_vi=
ew(&quot;Embedded\0Here&quot;).size().</div></div></div></div></blockquote>=
<div><br></div></span><div>In order to maintain invariant that strlen(zs.c_=
str()) =3D=3D zs.length() it would have to be 8. That is whenever you const=
ruct a zstring_vew from a string_view the implementation must scan the stri=
ng for nulls. </div></div></blockquote><div><br></div><div>If that is your =
invariant, then I really don&#39;t understand your zmstring_view idea.=C2=
=A0 Do you plan on checking every write to make sure none of them write a &=
#39;\0&#39;?=C2=A0 Or does your zmstring_view have a <i>different</i>=C2=A0=
invariant, which seems incredibly messy for users to deal with?</div><div><=
br></div><div>If you really want something like this standardized, put it i=
n your code base and get experience with what works and what doesn&#39;t.</=
div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot;=
 Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e014942045606800516162103--

.

------=_Part_51_1899506418.1431659958085
Content-Type: multipart/alternative;
 boundary="----=_Part_52_512471024.1431659958085"

------=_Part_52_512471024.1431659958085
Content-Type: text/plain; charset=UTF-8



On Thursday, May 14, 2015 at 11:06:31 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 14 May 2015 at 20:47, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> 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.
>

I think there has to be the invariant, otherwise the type doesn't make any
sense. Its like passing around a char* with a cached call to strlen() in a
size_t. If you insert a null and don't update the cached length, your
algorithm will be incorrect. Pre-computing and caching the size is
important, particlarly when you want to do operations on the end of the
string such as stripping trailing whitespace.


> Do you plan on checking every write to make sure none of them write a
> '\0'?
>

One solution is undefined behavior if you write a '\0' to a zmstring_view.
Debug implementations could choose to check the writes at runtime. Using a
type like this provides a superior interface to passing (char*,size_t) as
both of these pieces of information are tied together within a single range
object.




--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_52_512471024.1431659958085
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, May 14, 2015 at 11:06:31 PM UTC-4, Ne=
vin ":-)" Liber 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">On 14 May 2015 at 20:47, Matthew Fioravante <span dir=3D"ltr">&lt;=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"y81GGiQf=
PcoJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">fmatth...@gmail.com</=
a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span>On Wednesday, May 13, 2015 at 10:39:56=
 AM UTC-4, Nevin ":-)" Liber 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"><div><div class=3D"gmail_quote"><div>&nbsp;what is the re=
sult of zstring_view("Embedded\0Here")<wbr>.size().</div></div></div></div>=
</blockquote><div><br></div></span><div>In order to maintain invariant that=
 strlen(zs.c_str()) =3D=3D zs.length() it would have to be 8. That is whene=
ver you construct a zstring_vew from a string_view the implementation must =
scan the string for nulls. </div></div></blockquote><div><br></div><div>If =
that is your invariant, then I really don't understand your zmstring_view i=
dea.&nbsp; </div></div></div></div></blockquote><div><br></div><div>I think=
 there has to be the invariant, otherwise the type doesn't make any sense. =
Its like passing around a char* with a cached call to strlen() in a size_t.=
&nbsp;If you insert a null and don't update the cached length, your algorit=
hm will be incorrect.&nbsp;Pre-computing and caching the size is important,=
 particlarly when you want to do operations on the end of the string such a=
s stripping trailing whitespace.</div><div>&nbsp;</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><=
div>Do you plan on checking every write to make sure none of them write a '=
\0'?&nbsp; </div></div></div></div></blockquote><div><br></div><div>One sol=
ution is undefined behavior if you write a '\0' to a zmstring_view. Debug i=
mplementations could choose to check the writes at runtime. Using a type li=
ke this provides a superior interface to passing (char*,size_t) as both of =
these pieces of information are tied together within a single range object.=
</div><div><br></div><div><br></div><div>&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_52_512471024.1431659958085--
------=_Part_51_1899506418.1431659958085--

.

------=_Part_590_97703589.1431690190828
Content-Type: multipart/alternative;
 boundary="----=_Part_591_1426714015.1431690190828"

------=_Part_591_1426714015.1431690190828
Content-Type: text/plain; charset=UTF-8



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?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_591_1426714015.1431690190828
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Op woensdag 13 mei 2015 16:16:07 UTC+2 schreef Nic=
ol Bolas:<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"><div=
>So, you want to add an entire new type, just so that you don't have to typ=
e `.c_str()` after a std::string?<br></div></div></blockquote><div><br></di=
v><div>Yes. Are types too expensive for that?</div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Equally importa=
ntly, `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 lead=
ing characters, but you can't do anything more than that, since it has to b=
e null-terminated. You could never do Regex searches that return `zstring_v=
iew`s. And so forth.<br></div></div></blockquote><div><br></div><div>Obviou=
sly such functions would return a regular string_view.</div><div>&nbsp;</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Person=
ally, I prefer option 2. The user has to allocate memory, but they don't ha=
ve to put it there explicitly. It happens invisibly as a temporary. Or at l=
east, it can, depending on the source type.<br></div></div></blockquote><di=
v><br></div><div>I am not a fan of such unnecessary allocations.</div><div>=
<br></div><div>Why do you prefer 2? Do you agree that not having to use ().=
c_str() is a benefit?</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_591_1426714015.1431690190828--
------=_Part_590_97703589.1431690190828--

.

------=_Part_543_953826543.1431690376035
Content-Type: multipart/alternative;
 boundary="----=_Part_544_2144766993.1431690376035"

------=_Part_544_2144766993.1431690376035
Content-Type: text/plain; charset=UTF-8

Op woensdag 13 mei 2015 16:39:56 UTC+2 schreef Nevin ":-)" Liber:
>
> On 13 May 2015 at 06:13, Olaf van der Spek <olafv...@gmail.com
> <javascript:>> 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().
>

Same as string_view("Embedded\0Here").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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_544_2144766993.1431690376035
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Op woensdag 13 mei 2015 16:39:56 UTC+2 schreef Nevin ":-)"=
 Liber:<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">On 13 =
May 2015 at 06:13, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"mve4oQpx8RwJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">olafv...@gmail.com</a>&gt;</span> wro=
te:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div>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 g=
eneric then string_view but as C functions aren't going anywhere any time s=
oon it might still be handy.</div></div></blockquote><div><br></div><div>I =
rather see something like this come from experience rather than invention &=
nbsp;It is unclear how useful it would be in practice.&nbsp; There are also=
 some rather obvious interface questions, such as what is the result of zst=
ring_view("Embedded\0Here")<wbr>.size().</div></div></div></div></blockquot=
e><div><br></div><div>Same as string_view("Embedded\0Here")<wbr>.size() ?&n=
bsp;</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_544_2144766993.1431690376035--
------=_Part_543_953826543.1431690376035--

.

------=_Part_670_1469349915.1431696225198
Content-Type: multipart/alternative;
 boundary="----=_Part_671_1449564552.1431696225198"

------=_Part_671_1449564552.1431696225198
Content-Type: text/plain; charset=UTF-8

On Friday, May 15, 2015 at 7:43:10 AM UTC-4, Olaf van der Spek wrote:
>
> 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?
>

Yes, they are.

Every new type you add has a cost, even if that cost is only in the
programmer's head when he asks "what type should I use here?" Adding more
types increases the cost of this question, as it makes it more likely for
the programmer to get it wrong. To create a whole type for the primary
purpose of avoiding the use of a member function increases this burden to
no great advantage.

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.
>

And if I have a string_view, I need to do an allocation to get the
null-terminator in place. So it's hardly "unnecessary". It's only
"unnecessary" if the user just so happened to already have one of your
`zstring_view`s.

Why do you prefer 2? Do you agree that not having to use ().c_str() is a
> benefit?
>

 I gave you the reason: if you needed memory allocations, you don't have to
litter your code with zstring_view-to-std::string conversions.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_671_1449564552.1431696225198
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, May 15, 2015 at 7:43:10 AM UTC-4, Olaf van der =
Spek 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">Op=
 woensdag 13 mei 2015 16:16:07 UTC+2 schreef Nicol Bolas:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>So, you want to add an entire =
new type, just so that you don't have to type `.c_str()` after a std::strin=
g?<br></div></div></blockquote><div><br></div><div>Yes. Are types too expen=
sive for that?</div></div></blockquote><div><br>Yes, they are.<br><br>Every=
 new type you add has a cost, even if that cost is only in the programmer's=
 head when he asks "what type should I use here?" Adding more types increas=
es the cost of this question, as it makes it more likely for the programmer=
 to get it wrong. To create a whole type for the primary purpose of avoidin=
g the use of a member function increases this burden to no great advantage.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Equally impo=
rtantly, `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 l=
eading characters, but you can't do anything more than that, since it has t=
o be null-terminated. You could never do Regex searches that return `zstrin=
g_view`s. And so forth.<br></div></div></blockquote><div><br></div><div>Obv=
iously such functions would return a regular string_view.</div><div>&nbsp;<=
/div><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"><div>Personal=
ly, 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 lea=
st, it can, depending on the source type.<br></div></div></blockquote><div>=
<br></div><div>I am not a fan of such unnecessary allocations.</div></div><=
/blockquote><div><br>And if I have a string_view, I need to do an allocatio=
n to get the null-terminator in place. So it's hardly "unnecessary". It's o=
nly "unnecessary" if the user just so happened to already have one of your =
`zstring_view`s.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>Why do you prefer 2? Do you agree that not having to =
use ().c_str() is a benefit?<br></div></div></blockquote><div><br>&nbsp;I g=
ave you the reason: if you needed memory allocations, you don't have to lit=
ter your code with zstring_view-to-std::string conversions.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_671_1449564552.1431696225198--
------=_Part_670_1469349915.1431696225198--

.

2015-05-15 15:23 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
>>> 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.
>
>
> And if I have a string_view, I need to do an allocation to get the
> null-terminator in place. So it's hardly "unnecessary". It's only

Eh, it's either necessary or it's not. If you've already got a
null-terminated string but it's not a std::string then the allocation
is unnecessary...


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.