------=_Part_1871_1365945928.1502214366716
Content-Type: multipart/alternative;
 boundary="----=_Part_1872_666403269.1502214366717"

------=_Part_1872_666403269.1502214366717
Content-Type: text/plain; charset="UTF-8"

I'd like to propose a simple addition to std::basic_fstream:

Currently, there's two overloads for std::basic_fstream::open.

void open( const char *filename,
    ios_base::openmode mode = ios_base::in|ios_base::out );






void open( const std::string
<http://de.cppreference.com/w/cpp/string/basic_string> &filename,

    ios_base::openmode mode = ios_base::in|ios_base::out );

That means that when making extensive use of string_view, I'd have to
create a temporary std::string to open a filestream in a safe way. I
suggest adding a third overload:

void open( const std::string
<http://de.cppreference.com/w/cpp/string/basic_string>_view &filename,

    ios_base::openmode mode = ios_base::in|ios_base::out );

plus an addition overload for this in the constructor. It would require the
same addition to std::basic_filebuf::open. From what I can tell, it looks
feasable. Any objections/further suggestions?

--
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/cb7b55ab-7113-4d99-949b-8568627d0b7f%40isocpp.org.

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

<div dir=3D"ltr">I&#39;d like to propose a simple addition to std::basic_fs=
tream: <br><br>Currently, there&#39;s two overloads for std::basic_fstream:=
:open.<br><span style=3D"color: #000;" class=3D"styled-by-prettify"></span>=
<br><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><div s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; overflow-wrap: break-word;" cl=
ass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><table class=3D"t-dcl-begin"><tbody><tr class=3D"t-dcl"><td class=3D"t-d=
cl-nopad"><div><span class=3D"mw-geshi cpp source-cpp"><span class=3D"kw4">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">void</span></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> open</span><spa=
n class=3D"br0"><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span class=3D"kw4"><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">const</span></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span class=3D"kw4"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">char</span></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span class=3D"sy2"><span style=3D"color: #=
660;" class=3D"styled-by-prettify">*</span></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">filename</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 ios_base</span><span class=3D"sy4=
"><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span></span=
><span class=3D"me2"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">openmode</span></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> mode </span><span class=3D"sy1"><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> ios_base</span><span class=3D"sy4"><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span></span><span class=3D"=
me2"><span style=3D"color: #008;" class=3D"styled-by-prettify">in</span></s=
pan><span class=3D"sy3"><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">|</span></span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">ios_base</span><span class=3D"sy4"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span></span><span class=3D"me2"><span style=3D"=
color: #008;" class=3D"styled-by-prettify">out</span></span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span class=3D"br0"><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span></span><span =
class=3D"sy4"><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span></span></span></div></td><td class=3D"t-dcl-nopad"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> =C2=A0<br></span></td><td class=3D"=
t-dcl-nopad"><span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=
=A0 <br></span></td></tr><tr class=3D"t-dcl-sep"><td><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span></td><td><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></td><td><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span></td></tr><tr class=3D=
"t-dcl t-dcl-since-cxx11"><td><span style=3D"color: #000;" class=3D"styled-=
by-prettify">=C2=A0</span><div><span class=3D"mw-geshi cpp source-cpp"><spa=
n class=3D"kw4"><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 open</span><span class=3D"br0"><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span class=3D"kw4"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><a href=3D"http://de.cppreference.com/w/c=
pp/string/basic_string"><span class=3D"kw1034"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span class=3D"me2"><span style=3D"color: =
#008;" class=3D"styled-by-prettify">string</span></span></span></a><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span class=3D"sy=
3"><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span></=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">filename</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 ios_base</span><span class=3D"sy4=
"><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span></span=
><span class=3D"me2"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">openmode</span></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> mode </span><span class=3D"sy1"><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> ios_base</span><span class=3D"sy4"><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span></span><span class=3D"=
me2"><span style=3D"color: #008;" class=3D"styled-by-prettify">in</span></s=
pan><span class=3D"sy3"><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">|</span></span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">ios_base</span><span class=3D"sy4"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span></span><span class=3D"me2"><span style=3D"=
color: #008;" class=3D"styled-by-prettify">out</span></span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span class=3D"br0"><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span></span><span =
class=3D"sy4"><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span></span></span></div></td></tr></tbody></table></div></code></div><br>T=
hat means that when making extensive use of string_view, I&#39;d have to cr=
eate a temporary std::string to open a filestream in a safe way. I suggest =
adding a third overload:<br><br><div style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><div><span class=3D"mw-geshi cpp s=
ource-cpp"><span class=3D"kw4"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">void</span></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> open</span><span class=3D"br0"><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span class=3D"kw4"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">const</span></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><a href=3D"http://de.cppre=
ference.com/w/cpp/string/basic_string"><span class=3D"kw1034"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span class=3D"me2"><span =
style=3D"color: #000;" class=3D"styled-by-prettify">string</span></span></s=
pan></a><span style=3D"color: #000;" class=3D"styled-by-prettify">_view </s=
pan><span class=3D"sy3"><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&amp;</span></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">filename</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 ios_base</sp=
an><span class=3D"sy4"><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span></span><span class=3D"me2"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">openmode</span></span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> mode </span><span class=3D"sy1"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> ios_base</span><span class=
=3D"sy4"><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
></span><span class=3D"me2"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">in</span></span><span class=3D"sy3"><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">|</span></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">ios_base</span><span class=3D"sy4"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span></span><span class=
=3D"me2"><span style=3D"color: #008;" class=3D"styled-by-prettify">out</spa=
n></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span class=3D"br0"><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span></span><span class=3D"sy4"><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span></span></span></div></div></code></div><br>plu=
s an addition overload for this in the constructor. It would require the sa=
me addition to std::basic_filebuf::open. From what I can tell, it looks fea=
sable. Any objections/further suggestions?<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/cb7b55ab-7113-4d99-949b-8568627d0b7f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cb7b55ab-7113-4d99-949b-8568627d0b7f=
%40isocpp.org</a>.<br />

------=_Part_1872_666403269.1502214366717--

------=_Part_1871_1365945928.1502214366716--

.

On 2017-08-08 19:46, Julian Watzinger wrote:
> I'd like to propose a simple addition to std::basic_fstream:
>
> Currently, there's two overloads for std::basic_fstream::open.
>
> |
> voidopen(constchar*filename,
>      ios_base::openmodemode =ios_base::in|ios_base::out);
>
>
>
>
>
> voidopen(conststd::string
> <http://de.cppreference.com/w/cpp/string/basic_string>&filename,
>      ios_base::openmodemode =ios_base::in|ios_base::out);
>
> |
>
> That means that when making extensive use of string_view, I'd have to
> create a temporary std::string to open a filestream in a safe way. I
> suggest adding a third overload:
>
> |
> voidopen(conststd::string
> <http://de.cppreference.com/w/cpp/string/basic_string>_view &filename,
>      ios_base::openmodemode =ios_base::in|ios_base::out);
> |
>
> plus an addition overload for this in the constructor. It would require
> the same addition to std::basic_filebuf::open. From what I can tell, it
> looks feasable. Any objections/further suggestions?
>

One objection is that the file name is supposed to be a nul-terminated
string. The string_view is not required to be that.


     Bo Persson


--
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/omctnb%246nf%241%40blaine.gmane.org.

.

------=_Part_2684_1761852047.1502215184920
Content-Type: multipart/alternative;
 boundary="----=_Part_2685_380692044.1502215184920"

------=_Part_2685_380692044.1502215184920
Content-Type: text/plain; charset="UTF-8"

Am Dienstag, 8. August 2017 19:52:02 UTC+2 schrieb Bo Persson:


> One objection is that the file name is supposed to be a nul-terminated
> string. The string_view is not required to be that.
>
>
>      Bo Persson
>
>
>
I realize that this is the current state, which is why I said that I'd have
to create a temporary std::string from a std::string_view if I want to open
a file-stream safely; otherwise I could just call the "const char*
filename" overload from std::string_view::data().

Is there any technical reason why the filename would have to be
nul-terminated? Otherwise one could simply make an implementation for
open() that does not require a nul-terminated string but rather a (const
char* filename, size_t size) pair.

--
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/9f6c436a-852c-4665-bf9f-91415491cdec%40isocpp.org.

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

<div dir=3D"ltr">Am Dienstag, 8. August 2017 19:52:02 UTC+2 schrieb Bo Pers=
son:<br><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">One o=
bjection is that the file name is supposed to be a nul-terminated=20
<br>string. The string_view is not required to be that.
<br>
<br>
<br>=C2=A0 =C2=A0 =C2=A0Bo Persson
<br>
<br>
<br></blockquote><div><br>I realize that this is the current state, which i=
s why I said that I&#39;d have to create a temporary std::string from a std=
::string_view if I want to open a file-stream safely; otherwise I could jus=
t call the &quot;const char* filename&quot; overload from std::string_view:=
:data().<br><br>Is there any technical reason why the filename would have t=
o be nul-terminated? Otherwise one could simply make an implementation for =
open() that does not require a nul-terminated string but rather a (const ch=
ar* filename, size_t size) pair. <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/9f6c436a-852c-4665-bf9f-91415491cdec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9f6c436a-852c-4665-bf9f-91415491cdec=
%40isocpp.org</a>.<br />

------=_Part_2685_380692044.1502215184920--

------=_Part_2684_1761852047.1502215184920--

.

------=_Part_4569_681870126.1502215525315
Content-Type: multipart/alternative;
 boundary="----=_Part_4570_322853280.1502215525315"

------=_Part_4570_322853280.1502215525315
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 8, 2017 at 1:59:44 PM UTC-4, Julian Watzinger wrote:
>
> Am Dienstag, 8. August 2017 19:52:02 UTC+2 schrieb Bo Persson:
>
>
>> One objection is that the file name is supposed to be a nul-terminated
>> string. The string_view is not required to be that.
>>
>>
>>      Bo Persson
>>
>>
>>
> I realize that this is the current state, which is why I said that I'd
> have to create a temporary std::string from a std::string_view if I want to
> open a file-stream safely; otherwise I could just call the "const char*
> filename" overload from std::string_view::data().
>
> Is there any technical reason why the filename would have to be
> nul-terminated? Otherwise one could simply make an implementation for
> open() that does not require a nul-terminated string but rather a (const
> char* filename, size_t size) pair.
>

Yes, there are technical reasons. Pretty much every low-level file API uses
NUL-terminated strings. So either the stream itself has to make (or worse
allocate) a NUL-terminated copy, or we make you create a NUL-terminated
copy. I'd say it's better to do the latter than the former. No need to
promise something we can't deliver.

--
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/b27512b1-0234-45d7-867e-220f2625f13f%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, August 8, 2017 at 1:59:44 PM UTC-4, Julian Wat=
zinger wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Am Dienstag, 8. August 2017 19:52:02 UTC+2 schrieb Bo Persson:<br><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">One objection is that the =
file name is supposed to be a nul-terminated=20
<br>string. The string_view is not required to be that.
<br>
<br>
<br>=C2=A0 =C2=A0 =C2=A0Bo Persson
<br>
<br>
<br></blockquote><div><br>I realize that this is the current state, which i=
s why I said that I&#39;d have to create a temporary std::string from a std=
::string_view if I want to open a file-stream safely; otherwise I could jus=
t call the &quot;const char* filename&quot; overload from std::string_view:=
:data().<br><br>Is there any technical reason why the filename would have t=
o be nul-terminated? Otherwise one could simply make an implementation for =
open() that does not require a nul-terminated string but rather a (const ch=
ar* filename, size_t size) pair. <br></div></div></blockquote><div><br>Yes,=
 there are technical reasons. Pretty much every low-level file API uses NUL=
-terminated strings. So either the stream itself has to make (or worse allo=
cate) a NUL-terminated copy, or we make you create a NUL-terminated copy. I=
&#39;d say it&#39;s better to do the latter than the former. No need to pro=
mise something we can&#39;t deliver.<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/b27512b1-0234-45d7-867e-220f2625f13f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b27512b1-0234-45d7-867e-220f2625f13f=
%40isocpp.org</a>.<br />

------=_Part_4570_322853280.1502215525315--

------=_Part_4569_681870126.1502215525315--

.

------=_Part_4629_1655874293.1502216184571
Content-Type: multipart/alternative;
 boundary="----=_Part_4630_1292191742.1502216184572"

------=_Part_4630_1292191742.1502216184572
Content-Type: text/plain; charset="UTF-8"

Ah, I see. I definately agree on the notion that in this case, its better
that I create a copy myself.

Is there any chance that low-level APIs will be moving away from
nul-terminated strings in the future? Having a lot of low-level functions
require a nul-terminated string kind of dampends the overall usefulness of
string_view IMHO.
At least from what I can tell after a few days worth of porting to
string_view - at first I though it would be a direct replacement for most
places where "const std::string&" was being used, but now it seems there's
a lot more consideration to be done, not to end up with more
temporaries/allocations than before.

Am Dienstag, 8. August 2017 20:05:25 UTC+2 schrieb Nicol Bolas:
>
> On Tuesday, August 8, 2017 at 1:59:44 PM UTC-4, Julian Watzinger wrote:
>>
>> Am Dienstag, 8. August 2017 19:52:02 UTC+2 schrieb Bo Persson:
>>
>>
>>> One objection is that the file name is supposed to be a nul-terminated
>>> string. The string_view is not required to be that.
>>>
>>>
>>>      Bo Persson
>>>
>>>
>>>
>> I realize that this is the current state, which is why I said that I'd
>> have to create a temporary std::string from a std::string_view if I want to
>> open a file-stream safely; otherwise I could just call the "const char*
>> filename" overload from std::string_view::data().
>>
>> Is there any technical reason why the filename would have to be
>> nul-terminated? Otherwise one could simply make an implementation for
>> open() that does not require a nul-terminated string but rather a (const
>> char* filename, size_t size) pair.
>>
>
> Yes, there are technical reasons. Pretty much every low-level file API
> uses NUL-terminated strings. So either the stream itself has to make (or
> worse allocate) a NUL-terminated copy, or we make you create a
> NUL-terminated copy. I'd say it's better to do the latter than the former.
> No need to promise something we can't deliver.
>

--
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/9fedbad3-c6f6-4dbe-a215-814666c52c6b%40isocpp.org.

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

<div dir=3D"ltr">Ah, I see. I definately agree on the notion that in this c=
ase, its better that I create a copy myself. <br><br>Is there any chance th=
at low-level APIs will be moving away from nul-terminated strings in the fu=
ture? Having a lot of low-level functions require a nul-terminated string k=
ind of dampends the overall usefulness of string_view IMHO. <br>At least fr=
om what I can tell after a few days worth of porting to string_view - at fi=
rst I though it would be a direct replacement for most places where &quot;c=
onst std::string&amp;&quot; was being used, but now it seems there&#39;s a =
lot more consideration to be done, not to end up with more temporaries/allo=
cations than before.<br><br>Am Dienstag, 8. August 2017 20:05:25 UTC+2 schr=
ieb Nicol 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"lt=
r">On Tuesday, August 8, 2017 at 1:59:44 PM UTC-4, Julian Watzinger 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">Am Dienstag, 8. Aug=
ust 2017 19:52:02 UTC+2 schrieb Bo Persson:<br><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex">One objection is that the file name is suppose=
d to be a nul-terminated=20
<br>string. The string_view is not required to be that.
<br>
<br>
<br>=C2=A0 =C2=A0 =C2=A0Bo Persson
<br>
<br>
<br></blockquote><div><br>I realize that this is the current state, which i=
s why I said that I&#39;d have to create a temporary std::string from a std=
::string_view if I want to open a file-stream safely; otherwise I could jus=
t call the &quot;const char* filename&quot; overload from std::string_view:=
:data().<br><br>Is there any technical reason why the filename would have t=
o be nul-terminated? Otherwise one could simply make an implementation for =
open() that does not require a nul-terminated string but rather a (const ch=
ar* filename, size_t size) pair. <br></div></div></blockquote><div><br>Yes,=
 there are technical reasons. Pretty much every low-level file API uses NUL=
-terminated strings. So either the stream itself has to make (or worse allo=
cate) a NUL-terminated copy, or we make you create a NUL-terminated copy. I=
&#39;d say it&#39;s better to do the latter than the former. No need to pro=
mise something we can&#39;t deliver.<br></div></div></blockquote></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/9fedbad3-c6f6-4dbe-a215-814666c52c6b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9fedbad3-c6f6-4dbe-a215-814666c52c6b=
%40isocpp.org</a>.<br />

------=_Part_4630_1292191742.1502216184572--

------=_Part_4629_1655874293.1502216184571--

.

------=_Part_4654_392028770.1502218493634
Content-Type: multipart/alternative;
 boundary="----=_Part_4655_1736146628.1502218493634"

------=_Part_4655_1736146628.1502218493634
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 8, 2017 at 2:16:24 PM UTC-4, Julian Watzinger wrote:
>
> Ah, I see. I definately agree on the notion that in this case, its better
> that I create a copy myself.
>
> Is there any chance that low-level APIs will be moving away from
> nul-terminated strings in the future?
>

I rather doubt it. It's hardly high on most people's priority lists.

Having a lot of low-level functions require a nul-terminated string kind of
> dampends the overall usefulness of string_view IMHO.
>

Which is why I wrote my own `zstring_view` class, which explicitly
represents a view of a NUL-terminated string (it treats the NUL-terminator
the same way `std::string` does; you can look at it, but it's not
explicitly part of the `begin/end` range). It has some of the operations of
`string_view` (thanks to inheritance), but it removes or alters the ones
that subdivide from the end. For obvious reasons.

At least from what I can tell after a few days worth of porting to
> string_view - at first I though it would be a direct replacement for most
> places where "const std::string&" was being used, but now it seems there's
> a lot more consideration to be done, not to end up with more
> temporaries/allocations than before.
>

You have exactly expressed why I wrote `zstring_view`.

--
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/a5d35071-ebd9-4c12-94a0-71d991047a8d%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, August 8, 2017 at 2:16:24 PM UTC-4, Julian Wat=
zinger wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Ah, I see. I definately agree on the notion that in this case, its better t=
hat I create a copy myself. <br><br>Is there any chance that low-level APIs=
 will be moving away from nul-terminated strings in the future?</div></bloc=
kquote><div><br>I rather doubt it. It&#39;s hardly high on most people&#39;=
s priority lists.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">Having a lot of low-level functions require a nul-termina=
ted string kind of dampends the overall usefulness of string_view IMHO.<br>=
</div></blockquote><div><br>Which is why I wrote my own `zstring_view` clas=
s, which explicitly represents a view of a NUL-terminated string (it treats=
 the NUL-terminator the same way `std::string` does; you can look at it, bu=
t it&#39;s not explicitly part of the `begin/end` range). It has some of th=
e operations of `string_view` (thanks to inheritance), but it removes or al=
ters the ones that subdivide from the end. For obvious reasons.<br><br></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">At least fr=
om what I can tell after a few days worth of porting to string_view - at fi=
rst I though it would be a direct replacement for most places where &quot;c=
onst std::string&amp;&quot; was being used, but now it seems there&#39;s a =
lot more consideration to be done, not to end up with more temporaries/allo=
cations than before.<br></div></blockquote><div><br>You have exactly expres=
sed why I wrote `zstring_view`.</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/a5d35071-ebd9-4c12-94a0-71d991047a8d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a5d35071-ebd9-4c12-94a0-71d991047a8d=
%40isocpp.org</a>.<br />

------=_Part_4655_1736146628.1502218493634--

------=_Part_4654_392028770.1502218493634--

.

On Tuesday, 8 August 2017 11:16:24 PDT Julian Watzinger wrote:
> Is there any chance that low-level APIs will be moving away from
> nul-terminated strings in the future?

Zero.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/11274221.vCcM65GnI7%40tjmaciei-mobl1.

.

------=_Part_5202_848359589.1502271312100
Content-Type: multipart/alternative;
 boundary="----=_Part_5203_1411174733.1502271312100"

------=_Part_5203_1411174733.1502271312100
Content-Type: text/plain; charset="UTF-8"



Op dinsdag 8 augustus 2017 20:54:53 UTC+2 schreef Nicol Bolas:
>
> On Tuesday, August 8, 2017 at 2:16:24 PM UTC-4, Julian Watzinger wrote:
>>
>> Ah, I see. I definately agree on the notion that in this case, its better
>> that I create a copy myself.
>>
>> Is there any chance that low-level APIs will be moving away from
>> nul-terminated strings in the future?
>>
>
> I rather doubt it. It's hardly high on most people's priority lists.
>
> Having a lot of low-level functions require a nul-terminated string kind
>> of dampends the overall usefulness of string_view IMHO.
>>
>
> Which is why I wrote my own `zstring_view` class, which explicitly
> represents a view of a NUL-terminated string (it treats the NUL-terminator
> the same way `std::string` does; you can look at it, but it's not
> explicitly part of the `begin/end` range). It has some of the operations of
> `string_view` (thanks to inheritance), but it removes or alters the ones
> that subdivide from the end. For obvious reasons.
>
> At least from what I can tell after a few days worth of porting to
>> string_view - at first I though it would be a direct replacement for most
>> places where "const std::string&" was being used, but now it seems there's
>> a lot more consideration to be done, not to end up with more
>> temporaries/allocations than before.
>>
>
> You have exactly expressed why I wrote `zstring_view`.
>

Any plans to propose it for standardization?

--
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/8bff939d-098b-4797-85fc-bf286ab4423f%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Op dinsdag 8 augustus 2017 20:54:53 UTC+2 schreef =
Nicol Bolas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n Tuesday, August 8, 2017 at 2:16:24 PM UTC-4, Julian Watzinger wrote:<bloc=
kquote 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">Ah, I see. I definately=
 agree on the notion that in this case, its better that I create a copy mys=
elf. <br><br>Is there any chance that low-level APIs will be moving away fr=
om nul-terminated strings in the future?</div></blockquote><div><br>I rathe=
r doubt it. It&#39;s hardly high on most people&#39;s priority lists.<br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Having a l=
ot of low-level functions require a nul-terminated string kind of dampends =
the overall usefulness of string_view IMHO.<br></div></blockquote><div><br>=
Which is why I wrote my own `zstring_view` class, which explicitly represen=
ts a view of a NUL-terminated string (it treats the NUL-terminator the same=
 way `std::string` does; you can look at it, but it&#39;s not explicitly pa=
rt of the `begin/end` range). It has some of the operations of `string_view=
` (thanks to inheritance), but it removes or alters the ones that subdivide=
 from the end. For obvious reasons.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">At least from what I can tell after a few da=
ys worth of porting to string_view - at first I though it would be a direct=
 replacement for most places where &quot;const std::string&amp;&quot; was b=
eing used, but now it seems there&#39;s a lot more consideration to be done=
, not to end up with more temporaries/allocations than before.<br></div></b=
lockquote><div><br>You have exactly expressed why I wrote `zstring_view`.</=
div></div></blockquote><div><br></div><div>Any plans to propose it for stan=
dardization?=C2=A0</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/8bff939d-098b-4797-85fc-bf286ab4423f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8bff939d-098b-4797-85fc-bf286ab4423f=
%40isocpp.org</a>.<br />

------=_Part_5203_1411174733.1502271312100--

------=_Part_5202_848359589.1502271312100--

.

------=_Part_5279_1423461248.1502273630886
Content-Type: multipart/alternative;
 boundary="----=_Part_5280_1978312779.1502273630886"

------=_Part_5280_1978312779.1502273630886
Content-Type: text/plain; charset="UTF-8"

Am Dienstag, 8. August 2017 20:54:53 UTC+2 schrieb Nicol Bolas:
>
> I rather doubt it. It's hardly high on most people's priority lists.
>

Quite unfortunate :( Its one thing to have a c-style API, which I
personally dislike when compared to modern C++; but to have the API
rrestrict the input-data in such a way... I'll still hope that at some
point, now that we actually have string_view, people will start to see this
as a necessity :/

Which is why I wrote my own `zstring_view` class, which explicitly
> represents a view of a NUL-terminated string (it treats the NUL-terminator
> the same way `std::string` does; you can look at it, but it's not
> explicitly part of the `begin/end` range). It has some of the operations of
> `string_view` (thanks to inheritance), but it removes or alters the ones
> that subdivide from the end. For obvious reasons.


Huh, I ended up writing a similar class, though I ended up ditching it, as
it didn't work quite as expected for my codebase - ie. I ended up having to
convert from string_view to cstring_view so often that it became unbeareabe
pretty quickly.

I actually ended up with a hack of sort:

template<size_t Size, typename Type>
std::array<Type, Size> toAPI(std::base_string_view<Type> view) const
{
    std::array<Type, Size> vArray;

    view.copy(vArray.data(), Size);
    vArray[view.size()] = '\0';

    return vArray;
}

At least when calling fileIO/WinAPI functions usually there's a limit to
how many characters can be in a string (ie. MAX_PATH = 260), so I'd call
toAPI<MAX_PATH>(view), which doesn't invoke dynamic allocations and should
thus be faster then creating a string (untested, hopefully the array gets
affected by RVO/copy ellision).

--
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/eb44aadb-aa1b-4457-95c3-a05d7b193818%40isocpp.org.

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

<div dir=3D"ltr">Am Dienstag, 8. August 2017 20:54:53 UTC+2 schrieb Nicol B=
olas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I rather=
 doubt it. It&#39;s hardly high on most people&#39;s priority lists.<br></d=
iv></blockquote><div><br>Quite unfortunate :( Its one thing to have a c-sty=
le API, which I personally dislike when compared to modern C++; but to have=
 the API rrestrict the input-data in such a way... I&#39;ll still hope that=
 at some point, now that we actually have string_view, people will start to=
 see this as a necessity :/<br><br><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;">Which is why I wrote my own `zstring_view` class, which =
explicitly=20
represents a view of a NUL-terminated string (it treats the=20
NUL-terminator the same way `std::string` does; you can look at it, but=20
it&#39;s not explicitly part of the `begin/end` range). It has some of the=
=20
operations of `string_view` (thanks to inheritance), but it removes or=20
alters the ones that subdivide from the end. For obvious reasons.</blockquo=
te><div><br>Huh, I ended up writing a similar class, though I ended up ditc=
hing it, as it didn&#39;t work quite as expected for my codebase - ie. I en=
ded up having to convert from string_view to cstring_view so often that it =
became unbeareabe pretty quickly.<br><br>I actually ended up with a hack of=
 sort:<br><br><div style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-w=
rap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">template</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">si=
ze_t </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Size<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">, </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><code class=3D"pret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">typename=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Type</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"></span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"></span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"></span></code>&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">array</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Type</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Size</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> toAPI</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">base_string_view</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Type</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> view</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">array</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Type</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Size</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> vArray</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r>=C2=A0 =C2=A0 view</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>copy</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">vArray</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">data</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Size</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 =C2=A0 vArray</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">view</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">size</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()]<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #080;" class=3D"styled-by-prettify">&#39;\0&#39;</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> vArray</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span></div></code></div><br>At least when callin=
g fileIO/WinAPI functions usually there&#39;s a limit to how many character=
s can be in a string (ie. MAX_PATH =3D 260), so I&#39;d call toAPI&lt;MAX_P=
ATH&gt;(view), which doesn&#39;t invoke dynamic allocations and should thus=
 be faster then creating a string (untested, hopefully the array gets affec=
ted by RVO/copy ellision). <br></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/eb44aadb-aa1b-4457-95c3-a05d7b193818%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb44aadb-aa1b-4457-95c3-a05d7b193818=
%40isocpp.org</a>.<br />

------=_Part_5280_1978312779.1502273630886--

------=_Part_5279_1423461248.1502273630886--

.

On Wednesday, 9 August 2017 03:13:50 PDT Julian Watzinger wrote:
> Quite unfortunate  Its one thing to have a c-style API, which I
> personally dislike when compared to modern C++; but to have the API
> rrestrict the input-data in such a way... I'll still hope that at some
> point, now that we actually have string_view, people will start to see this
> as a necessity

Do you mean those C developers developing C API? Including people actively
hostile to C++, like Linus Torvalds?

When do you think they will see std::string_view as a necessity?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/3050218.VQ5TFqK1h4%40tjmaciei-mobl1.

.

------=_Part_5659_140491240.1502292430426
Content-Type: multipart/alternative;
 boundary="----=_Part_5660_1539777604.1502292430427"

------=_Part_5660_1539777604.1502292430427
Content-Type: text/plain; charset="UTF-8"



On Wednesday, August 9, 2017 at 11:04:17 AM UTC-4, Thiago Macieira wrote:
>
> On Wednesday, 9 August 2017 03:13:50 PDT Julian Watzinger wrote:
> > Quite unfortunate  Its one thing to have a c-style API, which I
> > personally dislike when compared to modern C++; but to have the API
> > rrestrict the input-data in such a way... I'll still hope that at some
> > point, now that we actually have string_view, people will start to see
> this
> > as a necessity
>
> Do you mean those C developers developing C API? Including people actively
> hostile to C++, like Linus Torvalds?
>
> When do you think they will see std::string_view as a necessity?
>

It's not about making them adopt `string_view` specifically. It's more
about them taking string+length. Right now, those APIs *require*
NUL-termination of strings.

But there are some C APIs that take a string+length. Lua, for example.
OpenGL's shader APIs are another example.

--
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/da7f5e95-c1b7-4119-aff2-8eb20fec0a48%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, August 9, 2017 at 11:04:17 AM UTC-4,=
 Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wedn=
esday, 9 August 2017 03:13:50 PDT Julian Watzinger wrote:
<br>&gt; Quite unfortunate =C2=A0Its one thing to have a c-style API, which=
 I
<br>&gt; personally dislike when compared to modern C++; but to have the AP=
I
<br>&gt; rrestrict the input-data in such a way... I&#39;ll still hope that=
 at some
<br>&gt; point, now that we actually have string_view, people will start to=
 see this
<br>&gt; as a necessity=20
<br>
<br>Do you mean those C developers developing C API? Including people activ=
ely=20
<br>hostile to C++, like Linus Torvalds?
<br>
<br>When do you think they will see std::string_view as a necessity?
<br></blockquote><div><br>It&#39;s not about making them adopt `string_view=
` specifically. It&#39;s more about them taking string+length. Right now, t=
hose APIs <i>require</i> NUL-termination of strings.<br><br>But there are s=
ome C APIs that take a string+length. Lua, for example. OpenGL&#39;s shader=
 APIs are another example.<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/da7f5e95-c1b7-4119-aff2-8eb20fec0a48%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/da7f5e95-c1b7-4119-aff2-8eb20fec0a48=
%40isocpp.org</a>.<br />

------=_Part_5660_1539777604.1502292430427--

------=_Part_5659_140491240.1502292430426--

.

------=_Part_5524_1460263296.1502292904389
Content-Type: multipart/alternative;
 boundary="----=_Part_5525_397010407.1502292904390"

------=_Part_5525_397010407.1502292904390
Content-Type: text/plain; charset="UTF-8"

On Wednesday, August 9, 2017 at 5:35:12 AM UTC-4, olafv...@gmail.com wrote:
>
> Op dinsdag 8 augustus 2017 20:54:53 UTC+2 schreef Nicol Bolas:
>>
>> On Tuesday, August 8, 2017 at 2:16:24 PM UTC-4, Julian Watzinger wrote:
>>>
>>> Ah, I see. I definately agree on the notion that in this case, its
>>> better that I create a copy myself.
>>>
>>> Is there any chance that low-level APIs will be moving away from
>>> nul-terminated strings in the future?
>>>
>>
>> I rather doubt it. It's hardly high on most people's priority lists.
>>
>> Having a lot of low-level functions require a nul-terminated string kind
>>> of dampends the overall usefulness of string_view IMHO.
>>>
>>
>> Which is why I wrote my own `zstring_view` class, which explicitly
>> represents a view of a NUL-terminated string (it treats the NUL-terminator
>> the same way `std::string` does; you can look at it, but it's not
>> explicitly part of the `begin/end` range). It has some of the operations of
>> `string_view` (thanks to inheritance), but it removes or alters the ones
>> that subdivide from the end. For obvious reasons.
>>
>> At least from what I can tell after a few days worth of porting to
>>> string_view - at first I though it would be a direct replacement for most
>>> places where "const std::string&" was being used, but now it seems there's
>>> a lot more consideration to be done, not to end up with more
>>> temporaries/allocations than before.
>>>
>>
>> You have exactly expressed why I wrote `zstring_view`.
>>
>
> Any plans to propose it for standardization?
>

Not really. As useful as `zstring_view` certainly is, I do not like the
idea of proliferating `string_view` types. The other problem is that there
aren't very many APIs in the C++ parts of the standard that specifically
need NUL-termination.

Now, that being said, P0645 includes a `cstring_view` type
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0645r0.html#StringView>,
which is just a `const char*` for a NUL-terminated string. That is, it has
no size, so `size` is linear. Personally, I think this is a horrible type
and I hope it gets revised during standardization into something more like
`zstring_view`. And that the system gets changed to one that can work based
on an actual `string_view`.

There's no excuse for making C++ APIs that depend on NUL-termiantion.

--
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/c63bfd77-b6b6-4b2f-ad3d-6d22210877ee%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, August 9, 2017 at 5:35:12 AM UTC-4, olafv...=
@gmail.com 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"l=
tr">Op dinsdag 8 augustus 2017 20:54:53 UTC+2 schreef Nicol Bolas:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, August 8, 2017 =
at 2:16:24 PM UTC-4, Julian Watzinger wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">Ah, I see. I definately agree on the notion that =
in this case, its better that I create a copy myself. <br><br>Is there any =
chance that low-level APIs will be moving away from nul-terminated strings =
in the future?</div></blockquote><div><br>I rather doubt it. It&#39;s hardl=
y high on most people&#39;s priority lists.<br><br></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">Having a lot of low-level functions=
 require a nul-terminated string kind of dampends the overall usefulness of=
 string_view IMHO.<br></div></blockquote><div><br>Which is why I wrote my o=
wn `zstring_view` class, which explicitly represents a view of a NUL-termin=
ated string (it treats the NUL-terminator the same way `std::string` does; =
you can look at it, but it&#39;s not explicitly part of the `begin/end` ran=
ge). It has some of the operations of `string_view` (thanks to inheritance)=
, but it removes or alters the ones that subdivide from the end. For obviou=
s reasons.<br><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">At least from what I can tell after a few days worth of porting to st=
ring_view - at first I though it would be a direct replacement for most pla=
ces where &quot;const std::string&amp;&quot; was being used, but now it see=
ms there&#39;s a lot more consideration to be done, not to end up with more=
 temporaries/allocations than before.<br></div></blockquote><div><br>You ha=
ve exactly expressed why I wrote `zstring_view`.</div></div></blockquote><d=
iv><br></div><div>Any plans to propose it for standardization?=C2=A0</div><=
/div></blockquote><div><br>Not really. As useful as `zstring_view` certainl=
y is, I do not like the idea of proliferating `string_view` types. The othe=
r problem is that there aren&#39;t very many APIs in the C++ parts of the s=
tandard that specifically need NUL-termination.<br><br>Now, that being said=
, <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0645r=
0.html#StringView">P0645 includes a `cstring_view` type</a>, which is just =
a `const char*` for a NUL-terminated string. That is, it has no size, so `s=
ize` is linear. Personally, I think this is a horrible type and I hope it g=
ets revised during standardization into something more like `zstring_view`.=
 And that the system gets changed to one that can work based on an actual `=
string_view`.<br><br>There&#39;s no excuse for making C++ APIs that depend =
on NUL-termiantion.<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/c63bfd77-b6b6-4b2f-ad3d-6d22210877ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c63bfd77-b6b6-4b2f-ad3d-6d22210877ee=
%40isocpp.org</a>.<br />

------=_Part_5525_397010407.1502292904390--

------=_Part_5524_1460263296.1502292904389--

.

On Tue, Aug 8, 2017 at 11:16 AM, Julian Watzinger <galaxy.wars@gmx.at> wrote:
> Ah, I see. I definately agree on the notion that in this case, its better
> that I create a copy myself.
>
> Is there any chance that low-level APIs will be moving away from
> nul-terminated strings in the future?

As folks have said, these are largely system calls, for which the cost
of migration is probably too high for the benefit that going to
pointer+length would provide.

However, being system calls, they also cost significantly more than
the cost of copying a path-length string, so don't be too afraid of
just doing that.

Jeffrey

--
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/CANh-dXmwXG%3DENS9UhjE25fGq6Kg1quaGNm2OW_Rh_oJLYKtw%3Dg%40mail.gmail.com.

.

------=_Part_5675_967828509.1502295574297
Content-Type: multipart/alternative;
 boundary="----=_Part_5676_437505246.1502295574297"

------=_Part_5676_437505246.1502295574297
Content-Type: text/plain; charset="UTF-8"


>
>
> At least when calling fileIO/WinAPI functions usually there's a limit to
> how many characters can be in a string (ie. MAX_PATH = 260), so I'd call
> toAPI<MAX_PATH>(view), which doesn't invoke dynamic allocations and should
> thus be faster then creating a string (untested, hopefully the array gets
> affected by RVO/copy ellision).
>

Recent Windows allow max path to reach 32K characters if a process opts
into it.

You should look at
https://ned14.github.io/afio/classafio__v2__xxx_1_1path__view.html and
specifically
https://ned14.github.io/afio/structafio__v2__xxx_1_1path__view_1_1c__str.html.
It is the correct solution to this problem and works very well, despite
slightly touching on UB. If the C++ standard could be improved to avoid
that slight UB, that would be very valuable instead of your original
request.

Niall

--
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/72ae8c14-96e8-4fd5-bad6-4e22a16615aa%40isocpp.org.

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

<div dir=3D"ltr"><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"l=
tr"><div><div><br>At least when calling fileIO/WinAPI functions usually the=
re&#39;s a limit to how many characters can be in a string (ie. MAX_PATH =
=3D 260), so I&#39;d call toAPI&lt;MAX_PATH&gt;(view), which doesn&#39;t in=
voke dynamic allocations and should thus be faster then creating a string (=
untested, hopefully the array gets affected by RVO/copy ellision). <br></di=
v></div></div></blockquote><div><br></div><div>Recent Windows allow max pat=
h to reach 32K characters if a process opts into it.</div><div><br></div><d=
iv>You should look at https://ned14.github.io/afio/classafio__v2__xxx_1_1pa=
th__view.html and specifically https://ned14.github.io/afio/structafio__v2_=
_xxx_1_1path__view_1_1c__str.html. It is the correct solution to this probl=
em and works very well, despite slightly touching on UB. If the C++ standar=
d could be improved to avoid that slight UB, that would be very valuable in=
stead of your original request.</div><div><br></div><div>Niall</div><div><b=
r></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/72ae8c14-96e8-4fd5-bad6-4e22a16615aa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72ae8c14-96e8-4fd5-bad6-4e22a16615aa=
%40isocpp.org</a>.<br />

------=_Part_5676_437505246.1502295574297--

------=_Part_5675_967828509.1502295574297--

.

On quarta-feira, 9 de agosto de 2017 08:35:04 PDT Nicol Bolas wrote:
> Now, that being said, P0645 includes a `cstring_view` type
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0645r0.html#String
> View>, which is just a `const char*` for a NUL-terminated string. That is,
> it has no size, so `size` is linear. Personally, I think this is a horrible
> type and I hope it gets revised during standardization into something more
> like `zstring_view`. And that the system gets changed to one that can work
> based on an actual `string_view`.

Either way, it's useful for an alternate main() function that could take C++
types. Transforming

 int main(int argc, char **argv)

into

 int main(std::initializer_list<std::cstring_view>)
 (or zstring_view or stringz_view or whatever you call it)

Can be achieved with one instruction added by the compiler into the main
function (which is special anyway).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/9163243.mWMLzuevxD%40tjmaciei-mobl1.

.

On quarta-feira, 9 de agosto de 2017 09:19:34 PDT Niall Douglas wrote:
> You should look at
> https://ned14.github.io/afio/classafio__v2__xxx_1_1path__view.html and
> specifically
> https://ned14.github.io/afio/structafio__v2__xxx_1_1path__view_1_1c__str.htm
> l. It is the correct solution to this problem and works very well, despite
> slightly touching on UB. If the C++ standard could be improved to avoid
> that slight UB, that would be very valuable instead of your original
> request.

What UB? The links don't talk about it.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/2453578.CALSNju9tS%40tjmaciei-mobl1.

.

On quarta-feira, 9 de agosto de 2017 09:15:59 PDT 'Jeffrey Yasskin' via ISO C+
+ Standard - Future Proposals wrote:
> However, being system calls, they also cost significantly more than
> the cost of copying a path-length string, so don't be too afraid of
> just doing that.

The problem is the copying an input of arbitrary length in an exception-free
and thread-safe manner.

You can't do malloc(), since that might fail. You can't use new[] because it
might throw. You can't lock a mutex because that is not async signal safe.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1894906.unAOSKiKQz%40tjmaciei-mobl1.

.

2017-08-09 21:49 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> On quarta-feira, 9 de agosto de 2017 09:15:59 PDT 'Jeffrey Yasskin' via ISO C+
> + Standard - Future Proposals wrote:
>> However, being system calls, they also cost significantly more than
>> the cost of copying a path-length string, so don't be too afraid of
>> just doing that.
>
> The problem is the copying an input of arbitrary length in an exception-free
> and thread-safe manner.

Exception-free or error-free?
Why does it have to be error-free? Generally the (system) call can fail too.



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HPGk8DVqtZjBQvbxTUbHmsdHhO%3DttZ28z08T_PL%2B75Nrw%40mail.gmail.com.

.

On quarta-feira, 9 de agosto de 2017 12:52:45 PDT Olaf van der Spek wrote:
> 2017-08-09 21:49 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> > On quarta-feira, 9 de agosto de 2017 09:15:59 PDT 'Jeffrey Yasskin' via
> > ISO C+>
> > + Standard - Future Proposals wrote:
> >> However, being system calls, they also cost significantly more than
> >> the cost of copying a path-length string, so don't be too afraid of
> >> just doing that.
> >
> > The problem is the copying an input of arbitrary length in an
> > exception-free and thread-safe manner.
>
> Exception-free or error-free?
> Why does it have to be error-free? Generally the (system) call can fail too.

Exception-free. And you can't call malloc (not async signal safe), you can't
lock a mutex or even a spinlock.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/62599054.mS6tLjcf7H%40tjmaciei-mobl1.

.

------=_Part_268_886286927.1502318389091
Content-Type: multipart/alternative;
 boundary="----=_Part_269_1529546960.1502318389091"

------=_Part_269_1529546960.1502318389091
Content-Type: text/plain; charset="UTF-8"


>
>
> What UB? The links don't talk about it.
>

It's only a hint of UB, not actual UB. I've improved the docs with a red
warning sign saying "the byte after the view must be readable".

Niall

--
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/45eb1803-dff3-42e0-873b-6d9f6ffe8a70%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>What UB? =
The links don&#39;t talk about it.
<br>
</blockquote><div><br></div><div>It&#39;s only a hint of UB, not actual UB.=
 I&#39;ve improved the docs with a red warning sign saying &quot;the byte a=
fter the view must be readable&quot;.</div><div><br></div><div>Niall</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/45eb1803-dff3-42e0-873b-6d9f6ffe8a70%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45eb1803-dff3-42e0-873b-6d9f6ffe8a70=
%40isocpp.org</a>.<br />

------=_Part_269_1529546960.1502318389091--

------=_Part_268_886286927.1502318389091--

.

On Wed, Aug 9, 2017 at 12:49 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On quarta-feira, 9 de agosto de 2017 09:15:59 PDT 'Jeffrey Yasskin' via ISO C+
> + Standard - Future Proposals wrote:
>> However, being system calls, they also cost significantly more than
>> the cost of copying a path-length string, so don't be too afraid of
>> just doing that.
>
> The problem is the copying an input of arbitrary length in an exception-free
> and thread-safe manner.
>
> You can't do malloc(), since that might fail. You can't use new[] because it
> might throw. You can't lock a mutex because that is not async signal safe.

Which are the low-level APIs that take null-terminated strings and are
also async-signal-safe and failure-free? (If I needed
exception-freedom I'd use new(nothrow) or catch the exception and turn
it into a failure.)

Thanks,
Jeffrey

--
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/CANh-dXn0iLxgvBbUFH0UrBM7jdumO_aPX%3DY1YxHAMdoBPrS7Cw%40mail.gmail.com.

.

------=_Part_344_753413992.1502321748517
Content-Type: multipart/alternative;
 boundary="----=_Part_345_1365660248.1502321748517"

------=_Part_345_1365660248.1502321748517
Content-Type: text/plain; charset="UTF-8"

Am Mittwoch, 9. August 2017 17:04:17 UTC+2 schrieb Thiago Macieira:
>
> Do you mean those C developers developing C API? Including people actively
> hostile to C++, like Linus Torvalds?
>
> When do you think they will see std::string_view as a necessity?
>
>
>
Well I said "hope", not "think" :>  Still astounds me how anyone can really
actively oppose C++ and support C at the same time, but... no, I have
nothing.

It's not about making them adopt `string_view` specifically. It's more
> about them taking string+length. Right now, those APIs *require*
> NUL-termination of strings.


Aye, thats the main points. Its one thing to have an API take (void*,
size_t) for some array-manipulation, but to have (void*) and require the
pointer to have a specific value at the end would be considered ludicrous,
outside of strings OFC (yeah there's the historal reason but meh...).

However, being system calls, they also cost significantly more than
> the cost of copying a path-length string, so don't be too afraid of
> just doing that.
>

Its not just that, but when I'm thinking about integrating
std::string_view, and now I'm running into situations where I actually need
to make more unnecessary copies then if I just sticked to "const
std::string&", thats at least something to consider. Thats literally the
first modern C++-feature where I noticed something like it - its like if,
say, std::unique_ptr sometimes forced you to create a temporary copy of the
owned object to be intercompatible with some API...

Recent Windows allow max path to reach 32K characters if a process opts
> into it.
>

Eh, I know why I hate developing with WinAPI :/






--
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/93c8a946-653f-4a29-ae5f-8ac8a824cbfd%40isocpp.org.

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

<div dir=3D"ltr">Am Mittwoch, 9. August 2017 17:04:17 UTC+2 schrieb Thiago =
Macieira:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Do you mean those C d=
evelopers developing C API? Including people actively=20
<br>hostile to C++, like Linus Torvalds?
<br>
<br>When do you think they will see std::string_view as a necessity?
<br>
<br>
<br></blockquote><div><br>Well I said &quot;hope&quot;, not &quot;think&quo=
t; :&gt;=C2=A0 Still astounds me how anyone can really actively oppose C++ =
and support C at the same time, but... no, I have nothing.<br><br><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;">It&#39;s not about making =
them adopt `string_view` specifically. It&#39;s more about them taking stri=
ng+length. Right now, those APIs <i>require</i> NUL-termination of strings.=
</blockquote><div><br>Aye, thats the main points. Its one thing to have an =
API take (void*, size_t) for some array-manipulation, but to have (void*) a=
nd require the pointer to have a specific value at the end would be conside=
red ludicrous, outside of strings OFC (yeah there&#39;s the historal reason=
 but meh...).<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e=
x;">However, being system calls, they also cost significantly more than
<br>the cost of copying a path-length string, so don&#39;t be too afraid of
<br>just doing that.
<br></blockquote><div><br>Its not just that, but when I&#39;m thinking abou=
t integrating std::string_view, and now I&#39;m running into situations whe=
re I actually need to make more unnecessary copies then if I just sticked t=
o &quot;const std::string&amp;&quot;, thats at least something to consider.=
 Thats literally the first modern C++-feature where I noticed something lik=
e it - its like if, say, std::unique_ptr sometimes forced you to create a t=
emporary copy of the owned object to be intercompatible with some API...<br=
><br><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>Recent =
Windows allow max path to reach 32K characters if a process opts into it.</=
div></blockquote><div><br>Eh, I know why I hate developing with WinAPI :/<b=
r><br><br>=C2=A0</div><br></div>=C2=A0<br></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/93c8a946-653f-4a29-ae5f-8ac8a824cbfd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/93c8a946-653f-4a29-ae5f-8ac8a824cbfd=
%40isocpp.org</a>.<br />

------=_Part_345_1365660248.1502321748517--

------=_Part_344_753413992.1502321748517--

.

------=_Part_306_1271376298.1502322281635
Content-Type: multipart/alternative;
 boundary="----=_Part_307_125353153.1502322281635"

------=_Part_307_125353153.1502322281635
Content-Type: text/plain; charset="UTF-8"

On Wednesday, August 9, 2017 at 7:35:48 PM UTC-4, galax...@gmx.at wrote:
>
> Am Mittwoch, 9. August 2017 17:04:17 UTC+2 schrieb Thiago Macieira:
>>
>> Do you mean those C developers developing C API? Including people
>> actively
>> hostile to C++, like Linus Torvalds?
>>
>> When do you think they will see std::string_view as a necessity?
>>
>>
>>
> Well I said "hope", not "think" :>  Still astounds me how anyone can
> really actively oppose C++ and support C at the same time, but... no, I
> have nothing.
>
> It's not about making them adopt `string_view` specifically. It's more
>> about them taking string+length. Right now, those APIs *require*
>> NUL-termination of strings.
>
>
> Aye, thats the main points. Its one thing to have an API take (void*,
> size_t) for some array-manipulation, but to have (void*) and require the
> pointer to have a specific value at the end would be considered ludicrous,
> outside of strings OFC (yeah there's the historal reason but meh...).
>

It's funny that you mention that, because I actually know of a few APIs
that do that. Namely... Lua (with luaL_Reg
<http://www.lua.org/manual/5.3/manual.html#luaL_Reg>) and OpenGL (
wgl/glXCreateContextAttribsARB
<https://www.khronos.org/registry/OpenGL/extensions/ARB/WGL_ARB_create_context.txt>).
Yes, the same ones that *don't* require NUL-termination for their strings.

Arrays with sentinel values are not as uncommon as you think. They're used
primarily on APIs where there is a genuine expectation that the receiving
function is only going to look at each item in turn, and only going to look
at it *once*. What they are *not* is the default case. Or the common case.

--
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/fe7ed7a4-8f7c-40ea-a1a0-1d861a5ac5f1%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, August 9, 2017 at 7:35:48 PM UTC-4, galax...=
@gmx.at wrote:<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"=
>Am Mittwoch, 9. August 2017 17:04:17 UTC+2 schrieb Thiago Macieira:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">Do you mean those C developers developing =
C API? Including people actively=20
<br>hostile to C++, like Linus Torvalds?
<br>
<br>When do you think they will see std::string_view as a necessity?
<br>
<br>
<br></blockquote><div><br>Well I said &quot;hope&quot;, not &quot;think&quo=
t; :&gt;=C2=A0 Still astounds me how anyone can really actively oppose C++ =
and support C at the same time, but... no, I have nothing.<br><br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">It&#39;s not about making them ado=
pt `string_view` specifically. It&#39;s more about them taking string+lengt=
h. Right now, those APIs <i>require</i> NUL-termination of strings.</blockq=
uote><div><br>Aye, thats the main points. Its one thing to have an API take=
 (void*, size_t) for some array-manipulation, but to have (void*) and requi=
re the pointer to have a specific value at the end would be considered ludi=
crous, outside of strings OFC (yeah there&#39;s the historal reason but meh=
....).<br></div></div></div></blockquote><div><br>It&#39;s funny that you me=
ntion that, because I actually know of a few APIs that do that. Namely... L=
ua (with <a href=3D"http://www.lua.org/manual/5.3/manual.html#luaL_Reg">lua=
L_Reg</a>) and OpenGL (<a href=3D"https://www.khronos.org/registry/OpenGL/e=
xtensions/ARB/WGL_ARB_create_context.txt">wgl/glXCreateContextAttribsARB</a=
>). Yes, the same ones that <i>don&#39;t</i> require NUL-termination for th=
eir strings.<br><br>Arrays with sentinel values are not as uncommon as you =
think. They&#39;re used primarily on APIs where there is a genuine expectat=
ion that the receiving function is only going to look at each item in turn,=
 and only going to look at it <i>once</i>. What they are <i>not</i> is the =
default case. Or the common case.</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/fe7ed7a4-8f7c-40ea-a1a0-1d861a5ac5f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fe7ed7a4-8f7c-40ea-a1a0-1d861a5ac5f1=
%40isocpp.org</a>.<br />

------=_Part_307_125353153.1502322281635--

------=_Part_306_1271376298.1502322281635--

.

------=_Part_310_1965582746.1502322853958
Content-Type: multipart/alternative;
 boundary="----=_Part_311_887330353.1502322853958"

------=_Part_311_887330353.1502322853958
Content-Type: text/plain; charset="UTF-8"



Am Donnerstag, 10. August 2017 01:44:41 UTC+2 schrieb Nicol Bolas:

> It's funny that you mention that, because I actually know of a few APIs
> that do that. Namely... Lua (with luaL_Reg
> <http://www.lua.org/manual/5.3/manual.html#luaL_Reg>) and OpenGL (
> wgl/glXCreateContextAttribsARB
> <https://www.khronos.org/registry/OpenGL/extensions/ARB/WGL_ARB_create_context.txt>).
> Yes, the same ones that *don't* require NUL-termination for their strings.
>
> Arrays with sentinel values are not as uncommon as you think. They're used
> primarily on APIs where there is a genuine expectation that the receiving
> function is only going to look at each item in turn, and only going to look
> at it *once*. What they are *not* is the default case. Or the common case.
>

Uh, at least its good to know those aren't default/common I suppose. Come
to think of it, I know of exactly one example where this is the case, DX11 (
D3DCompile
<https://msdn.microsoft.com/en-us/library/windows/desktop/dd607324(v=vs.85).aspx>
where the pDefines parameter requires {nulltr, nullptr}), but thats
literally the only time I saw it, and you can imagine how weirded out I was
by that.

--
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/2764f451-644d-4c04-80bb-e3d719582f1a%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Am Donnerstag, 10. August 2017 01:44:41 UTC+2 schr=
ieb Nicol Bolas:<br><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"ltr"><div>It&#39;s funny that you mention that, because I actually know=
 of a few APIs that do that. Namely... Lua (with <a href=3D"http://www.lua.=
org/manual/5.3/manual.html#luaL_Reg" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fww=
w.lua.org%2Fmanual%2F5.3%2Fmanual.html%23luaL_Reg\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNEOlb9Q_jCdFWKKHGKpRFoZT7-4xw&#39;;return true;" onclick=3D"t=
his.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.lua.org%2Fm=
anual%2F5.3%2Fmanual.html%23luaL_Reg\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNEOlb9Q_jCdFWKKHGKpRFoZT7-4xw&#39;;return true;">luaL_Reg</a>) and OpenGL =
(<a href=3D"https://www.khronos.org/registry/OpenGL/extensions/ARB/WGL_ARB_=
create_context.txt" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.khronos.org%2=
Fregistry%2FOpenGL%2Fextensions%2FARB%2FWGL_ARB_create_context.txt\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNGpe877gMVUDOyUixsEHWC54mDpHw&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2=
F%2Fwww.khronos.org%2Fregistry%2FOpenGL%2Fextensions%2FARB%2FWGL_ARB_create=
_context.txt\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGpe877gMVUDOyUixsEHWC5=
4mDpHw&#39;;return true;">wgl/<wbr>glXCreateContextAttribsARB</a>). Yes, th=
e same ones that <i>don&#39;t</i> require NUL-termination for their strings=
..<br><br>Arrays with sentinel values are not as uncommon as you think. They=
&#39;re used primarily on APIs where there is a genuine expectation that th=
e receiving function is only going to look at each item in turn, and only g=
oing to look at it <i>once</i>. What they are <i>not</i> is the default cas=
e. Or the common case.</div></div></blockquote><div><br>Uh, at least its go=
od to know those aren&#39;t default/common I suppose. Come to think of it, =
I know of exactly one example where this is the case, DX11 (<a href=3D"http=
s://msdn.microsoft.com/en-us/library/windows/desktop/dd607324(v=3Dvs.85).as=
px">D3DCompile</a> where the pDefines parameter requires {nulltr, nullptr})=
, but thats literally the only time I saw it, and you can imagine how weird=
ed out I was by that.<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/2764f451-644d-4c04-80bb-e3d719582f1a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2764f451-644d-4c04-80bb-e3d719582f1a=
%40isocpp.org</a>.<br />

------=_Part_311_887330353.1502322853958--

------=_Part_310_1965582746.1502322853958--

.

------=_Part_583_1627942040.1502349040394
Content-Type: multipart/alternative;
 boundary="----=_Part_584_1062436222.1502349040394"

------=_Part_584_1062436222.1502349040394
Content-Type: text/plain; charset="UTF-8"

Op donderdag 10 augustus 2017 00:39:49 UTC+2 schreef Niall Douglas:
>
>
>> What UB? The links don't talk about it.
>>
>
> It's only a hint of UB, not actual UB. I've improved the docs with a red
> warning sign saying "the byte after the view must be readable".
>

How is that not UB?


--
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/f5d9042a-3d7a-45d5-93e1-61641f391c54%40isocpp.org.

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

<div dir=3D"ltr">Op donderdag 10 augustus 2017 00:39:49 UTC+2 schreef Niall=
 Douglas:<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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><br>What UB? The links don&#39;t talk a=
bout it.
<br>
</blockquote><div><br></div><div>It&#39;s only a hint of UB, not actual UB.=
 I&#39;ve improved the docs with a red warning sign saying &quot;the byte a=
fter the view must be readable&quot;.</div></div></blockquote><div><br></di=
v><div>How is that not UB?=C2=A0</div><div>=C2=A0</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/f5d9042a-3d7a-45d5-93e1-61641f391c54%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f5d9042a-3d7a-45d5-93e1-61641f391c54=
%40isocpp.org</a>.<br />

------=_Part_584_1062436222.1502349040394--

------=_Part_583_1627942040.1502349040394--

.

------=_Part_858_1823647184.1502372685917
Content-Type: multipart/alternative;
 boundary="----=_Part_859_1147412902.1502372685917"

------=_Part_859_1147412902.1502372685917
Content-Type: text/plain; charset="UTF-8"

On Thursday, August 10, 2017 at 8:10:40 AM UTC+1, olafv...@gmail.com wrote:
>
> Op donderdag 10 augustus 2017 00:39:49 UTC+2 schreef Niall Douglas:
>>
>>
>>> What UB? The links don't talk about it.
>>>
>>
>> It's only a hint of UB, not actual UB. I've improved the docs with a red
>> warning sign saying "the byte after the view must be readable".
>>
>
> How is that not UB?
>
> The requirement in order to provide defined behaviour that the character
after the view must be readable is publicly documented. Failure by the end
user to ensure this leads to UB, specifically, a segfault.

Niall

--
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/ebf29cbb-b62d-40e2-9fc7-4527bd5db2df%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, August 10, 2017 at 8:10:40 AM UTC+1, olafv...=
@gmail.com 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"l=
tr">Op donderdag 10 augustus 2017 00:39:49 UTC+2 schreef Niall Douglas:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><br>What UB? The links don&#39;t talk about it.
<br>
</blockquote><div><br></div><div>It&#39;s only a hint of UB, not actual UB.=
 I&#39;ve improved the docs with a red warning sign saying &quot;the byte a=
fter the view must be readable&quot;.</div></div></blockquote><div><br></di=
v><div>How is that not UB?=C2=A0</div><div><br></div></div></blockquote><di=
v>The requirement in order to provide defined behaviour that the character =
after the view must be readable is publicly documented. Failure by the end =
user to ensure this leads to UB, specifically, a segfault.</div><div><br></=
div><div>Niall</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/ebf29cbb-b62d-40e2-9fc7-4527bd5db2df%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ebf29cbb-b62d-40e2-9fc7-4527bd5db2df=
%40isocpp.org</a>.<br />

------=_Part_859_1147412902.1502372685917--

------=_Part_858_1823647184.1502372685917--

.

On 2017-08-09 19:54, galaxy.wars@gmx.at wrote:
> Am Donnerstag, 10. August 2017 01:44:41 UTC+2 schrieb Nicol Bolas:
>> Arrays with sentinel values are not as uncommon as you think. They're used
>> primarily on APIs where there is a genuine expectation that the receiving
>> function is only going to look at each item in turn, and only going to look
>> at it *once*. What they are *not* is the default case. Or the common case.
>
> Uh, at least its good to know those aren't default/common I suppose. Come
> to think of it, I know of exactly one example where this is the case, DX11 (
> D3DCompile
> <https://msdn.microsoft.com/en-us/library/windows/desktop/dd607324(v=vs.85).aspx>
> where the pDefines parameter requires {nulltr, nullptr}), but thats
> literally the only time I saw it, and you can imagine how weirded out I was
> by that.

There are some examples also in PROJ.4. Actually, it's not that uncommon
(at least in *my* experience) when you have a static list of things to
have the last item be a sentinel value rather than writing the somewhat
messy logic to get the size of the list. (Again, this tends to apply
when the usual use of the list is to walk it, not index into it.) Even
in C++, I've used this pattern myself some times.

https://github.com/Kitware/vivia/blob/master/Libraries/VvVtkWidgets/vvTrackInfo.cxx#L51
- This is an example I wrote...

--
Matthew

--
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/a7342f21-f941-671d-f52c-891fcec0b864%40gmail.com.

.

On quarta-feira, 9 de agosto de 2017 16:21:37 PDT 'Jeffrey Yasskin' via ISO C+
+ Standard - Future Proposals wrote:
> > You can't do malloc(), since that might fail. You can't use new[] because
> > it might throw. You can't lock a mutex because that is not async signal
> > safe.
> Which are the low-level APIs that take null-terminated strings and are
> also async-signal-safe and failure-free? (If I needed
> exception-freedom I'd use new(nothrow) or catch the exception and turn
> it into a failure.)

open(), readlink(), stat(), and their *at() versions, exec*, etc.

See http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
for the full list (http://man7.org/linux/man-pages/man7/signal-safety.7.html
too).

I don't see a solution other than a thread-specific buffer of PATH_MAX size.
For Windows, that would be 64 kB, per thread.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1712024.NjvlIh9J0q%40tjmaciei-mobl1.

.

On Thu, Aug 10, 2017 at 8:59 AM, Thiago Macieira <thiago@macieira.org> wrote:
> On quarta-feira, 9 de agosto de 2017 16:21:37 PDT 'Jeffrey Yasskin' via ISO C+
> + Standard - Future Proposals wrote:
>> > You can't do malloc(), since that might fail. You can't use new[] because
>> > it might throw. You can't lock a mutex because that is not async signal
>> > safe.
>> Which are the low-level APIs that take null-terminated strings and are
>> also async-signal-safe and failure-free? (If I needed
>> exception-freedom I'd use new(nothrow) or catch the exception and turn
>> it into a failure.)
>
> open(), readlink(), stat(), and their *at() versions, exec*, etc.
>
> See http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
> for the full list (http://man7.org/linux/man-pages/man7/signal-safety.7.html
> too).

All of those have long lists of failure conditions, often including
ENOMEM. Adding "couldn't allocate user-space memory" doesn't seem like
the end of the world.

Jeffrey

--
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/CANh-dX%3D_vJGW1nxKEEjiSJ_%3D-%2BhkUab6i5KVSWJYe03ooBmnfA%40mail.gmail.com.

.

On Thu, Aug 10, 2017 at 2:28 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> On Thu, Aug 10, 2017 at 8:59 AM, Thiago Macieira <thiago@macieira.org> wrote:
>> On quarta-feira, 9 de agosto de 2017 16:21:37 PDT 'Jeffrey Yasskin' via ISO C+
>> + Standard - Future Proposals wrote:
>>> > You can't do malloc(), since that might fail. You can't use new[] because
>>> > it might throw. You can't lock a mutex because that is not async signal
>>> > safe.
>>> Which are the low-level APIs that take null-terminated strings and are
>>> also async-signal-safe and failure-free? (If I needed
>>> exception-freedom I'd use new(nothrow) or catch the exception and turn
>>> it into a failure.)
>>
>> open(), readlink(), stat(), and their *at() versions, exec*, etc.
>>
>> See http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
>> for the full list (http://man7.org/linux/man-pages/man7/signal-safety.7.html
>> too).
>
> All of those have long lists of failure conditions, often including
> ENOMEM. Adding "couldn't allocate user-space memory" doesn't seem like
> the end of the world.

Ah, but you'll fall back to just wanting to write a signal-safe
function, even if it can fail. In that case, you probably do need to
operate on char*s and avoid almost the entire C++ library. We haven't
even said that std::string_view is signal-safe, even though we might
be able to say that.

Jeffrey

--
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/CANh-dX%3DK%2BFpo5yVrOEzKyRva1c6-JczH%3Dx6v2EWn0D%3DCG%2BEsmw%40mail.gmail.com.

.

On quinta-feira, 10 de agosto de 2017 14:32:28 PDT 'Jeffrey Yasskin' via ISO C
++ Standard - Future Proposals wrote:
> > All of those have long lists of failure conditions, often including
> > ENOMEM. Adding "couldn't allocate user-space memory" doesn't seem like
> > the end of the world.
>
> Ah, but you'll fall back to just wanting to write a signal-safe
> function, even if it can fail. In that case, you probably do need to
> operate on char*s and avoid almost the entire C++ library. We haven't
> even said that std::string_view is signal-safe, even though we might
> be able to say that.

We may also want to pay some attention to the POSIX asynchronous cancellation
points and how they relate to exceptions.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1946499.J2ei2Rq2Ih%40tjmaciei-mobl1.

.

On Thu, Aug 10, 2017 at 7:31 PM, Thiago Macieira <thiago@macieira.org> wrote:
>
> On quinta-feira, 10 de agosto de 2017 14:32:28 PDT 'Jeffrey Yasskin' via ISO C
> ++ Standard - Future Proposals wrote:
> > > All of those have long lists of failure conditions, often including
> > > ENOMEM. Adding "couldn't allocate user-space memory" doesn't seem like
> > > the end of the world.
> >
> > Ah, but you'll fall back to just wanting to write a signal-safe
> > function, even if it can fail. In that case, you probably do need to
> > operate on char*s and avoid almost the entire C++ library. We haven't
> > even said that std::string_view is signal-safe, even though we might
> > be able to say that.
>
> We may also want to pay some attention to the POSIX asynchronous cancellation
> points and how they relate to exceptions.

SG1 spent a lot of time on that when designing the C++11 threading
library, and couldn't find a way to make POSIX cancellation fit into
C++. You're welcome to spend more of your own time thinking about it,
but there's unlikely to be a fit.

Jeffrey

--
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/CANh-dXkT8-Znfyi5Wjj0qj7c%3D-yt5%2BhLXmgw%2BbZUUN5QRGRLtg%40mail.gmail.com.

.

On quinta-feira, 10 de agosto de 2017 20:41:46 PDT 'Jeffrey Yasskin' via ISO C
++ Standard - Future Proposals wrote:
> SG1 spent a lot of time on that when designing the C++11 threading
> library, and couldn't find a way to make POSIX cancellation fit into
> C++. You're welcome to spend more of your own time thinking about it,
> but there's unlikely to be a fit.

Sorry, I misspoke. We were talking about async-signal safety and I wrote
"asynchronous cancellation". Asynchronous cancellation is really hard and
really incompatible with proper exception-safety and unwinding.

I meant the *synchronous* cancellation, which can only happen in functions
that are clearly specified to be cancellation points.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/2113027.SkxpknQi9z%40tjmaciei-mobl1.

.

2017-08-10 15:44 GMT+02:00 Niall Douglas <nialldouglas14@gmail.com>:
> On Thursday, August 10, 2017 at 8:10:40 AM UTC+1, olafv...@gmail.com wrote:
>>
>> Op donderdag 10 augustus 2017 00:39:49 UTC+2 schreef Niall Douglas:
>>>>
>>>>
>>>> What UB? The links don't talk about it.
>>>
>>>
>>> It's only a hint of UB, not actual UB. I've improved the docs with a red
>>> warning sign saying "the byte after the view must be readable".
>>
>>
>> How is that not UB?
>>
> The requirement in order to provide defined behaviour that the character
> after the view must be readable is publicly documented.

Ouch. IMO that's not a reasonable requirement / interface.

> Failure by the end
> user to ensure this leads to UB, specifically, a segfault.

What could the committee do about this?


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HNUMs_QRbxqm8kS41UNkNN6D_2AJWVOk%2BPCwgfYM2mnjg%40mail.gmail.com.

.

2017-08-10 23:28 GMT+02:00 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org>:
> On Thu, Aug 10, 2017 at 8:59 AM, Thiago Macieira <thiago@macieira.org> wrote:
>> On quarta-feira, 9 de agosto de 2017 16:21:37 PDT 'Jeffrey Yasskin' via ISO C+
>> + Standard - Future Proposals wrote:
>>> > You can't do malloc(), since that might fail. You can't use new[] because
>>> > it might throw. You can't lock a mutex because that is not async signal
>>> > safe.
>>> Which are the low-level APIs that take null-terminated strings and are
>>> also async-signal-safe and failure-free? (If I needed
>>> exception-freedom I'd use new(nothrow) or catch the exception and turn
>>> it into a failure.)
>>
>> open(), readlink(), stat(), and their *at() versions, exec*, etc.
>>
>> See http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
>> for the full list (http://man7.org/linux/man-pages/man7/signal-safety.7.html
>> too).
>
> All of those have long lists of failure conditions, often including
> ENOMEM. Adding "couldn't allocate user-space memory" doesn't seem like
> the end of the world.

What's the proper design for such interfaces though?
zstring_view seems best but doesn't exist.
const char* wouldn't do any unnecessary allocations.
Both string_view and string might do unnecessary allocations

What do kernels use internally? If they use ptr/size there might be a
chance for a ptr/size interface, if they don't we're stuck with
termination.


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HM%3Da7%3D%3Dw_ruj%3D7XAE-00KC2nDJh5wtodhQgW3v8LuVWEA%40mail.gmail.com.

.

------=_Part_2349_822363178.1502468869100
Content-Type: multipart/alternative;
 boundary="----=_Part_2350_945262346.1502468869101"

------=_Part_2350_945262346.1502468869101
Content-Type: text/plain; charset="UTF-8"



Am Donnerstag, 10. August 2017 15:49:07 UTC+2 schrieb Matthew Woehlke:
>
> On 2017-08-09 19:54, galax...@gmx.at <javascript:> wrote:
> > Am Donnerstag, 10. August 2017 01:44:41 UTC+2 schrieb Nicol Bolas:
> >> Arrays with sentinel values are not as uncommon as you think. They're
> used
> >> primarily on APIs where there is a genuine expectation that the
> receiving
> >> function is only going to look at each item in turn, and only going to
> look
> >> at it *once*. What they are *not* is the default case. Or the common
> case.
> >
> > Uh, at least its good to know those aren't default/common I suppose.
> Come
> > to think of it, I know of exactly one example where this is the case,
> DX11 (
> > D3DCompile
> > <
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd607324(v=vs.85).aspx>
>
> > where the pDefines parameter requires {nulltr, nullptr}), but thats
> > literally the only time I saw it, and you can imagine how weirded out I
> was
> > by that.
>
> There are some examples also in PROJ.4. Actually, it's not that uncommon
> (at least in *my* experience) when you have a static list of things to
> have the last item be a sentinel value rather than writing the somewhat
> messy logic to get the size of the list. (Again, this tends to apply
> when the usual use of the list is to walk it, not index into it.) Even
> in C++, I've used this pattern myself some times.
>
>
> https://github.com/Kitware/vivia/blob/master/Libraries/VvVtkWidgets/vvTrackInfo.cxx#L51
> - This is an example I wrote...
>
> --
> Matthew
>

Okay, appearently its not that uncommon. But its seems mostly for
high-levelish work that could be worked around if necessary. In case of
file-IO, its pretty low level and basic, and imposes a restriction that
cannot be worked around (= rebuild funcionality manually) in any way. Its
kind of like if memcpy, memcmp etc... requires the end of the data-pointers
passed in to contain a certain escape-sequence.

I'll rest my case though and hope that some other solution like the ones
mentioned are proposed - though as I said I personally didn't feel that
CStringView/ZStringView worked out quite as well as expected, it just
pushed the burden of constructing the temporary-string further up to the
user of the abstractions instead of the abstaction itself. Might revisit it
once I'm done porting the whole codebase to StringView though.

--
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/615c471b-87aa-4a9b-a006-b9612965d6e3%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Am Donnerstag, 10. August 2017 15:49:07 UTC+2 schr=
ieb Matthew Woehlke:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-08=
-09 19:54, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"5LPlE3d2BwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">galax...@gmx.at</a> wrote:
<br>&gt; Am Donnerstag, 10. August 2017 01:44:41 UTC+2 schrieb Nicol Bolas:
<br>&gt;&gt; Arrays with sentinel values are not as uncommon as you think. =
They&#39;re used=20
<br>&gt;&gt; primarily on APIs where there is a genuine expectation that th=
e receiving=20
<br>&gt;&gt; function is only going to look at each item in turn, and only =
going to look=20
<br>&gt;&gt; at it *once*. What they are *not* is the default case. Or the =
common case.
<br>&gt;=20
<br>&gt; Uh, at least its good to know those aren&#39;t default/common I su=
ppose. Come=20
<br>&gt; to think of it, I know of exactly one example where this is the ca=
se, DX11 (
<br>&gt; D3DCompile=20
<br>&gt; &lt;<a href=3D"https://msdn.microsoft.com/en-us/library/windows/de=
sktop/dd607324(v=3Dvs.85).aspx" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fmsdn.=
microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Fdd607324(v%3Dvs.85).a=
spx\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHhBNYTk4Z_ae38Oc8c4JGm2DH10g&#3=
9;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x=
3dhttps%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2F=
dd607324(v%3Dvs.85).aspx\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHhBNYTk4Z_=
ae38Oc8c4JGm2DH10g&#39;;return true;">https://msdn.microsoft.com/<wbr>en-us=
/library/windows/desktop/<wbr>dd607324(v=3Dvs.85).aspx</a>&gt;=20
<br>&gt; where the pDefines parameter requires {nulltr, nullptr}), but that=
s=20
<br>&gt; literally the only time I saw it, and you can imagine how weirded =
out I was=20
<br>&gt; by that.
<br>
<br>There are some examples also in PROJ.4. Actually, it&#39;s not that unc=
ommon
<br>(at least in *my* experience) when you have a static list of things to
<br>have the last item be a sentinel value rather than writing the somewhat
<br>messy logic to get the size of the list. (Again, this tends to apply
<br>when the usual use of the list is to walk it, not index into it.) Even
<br>in C++, I&#39;ve used this pattern myself some times.
<br>
<br><a href=3D"https://github.com/Kitware/vivia/blob/master/Libraries/VvVtk=
Widgets/vvTrackInfo.cxx#L51" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.c=
om%2FKitware%2Fvivia%2Fblob%2Fmaster%2FLibraries%2FVvVtkWidgets%2FvvTrackIn=
fo.cxx%23L51\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFNA9c9JApYNYwIX0ayXzX5=
gHKqgQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.co=
m/url?q\x3dhttps%3A%2F%2Fgithub.com%2FKitware%2Fvivia%2Fblob%2Fmaster%2FLib=
raries%2FVvVtkWidgets%2FvvTrackInfo.cxx%23L51\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNFNA9c9JApYNYwIX0ayXzX5gHKqgQ&#39;;return true;">https://github.c=
om/Kitware/<wbr>vivia/blob/master/Libraries/<wbr>VvVtkWidgets/vvTrackInfo.c=
xx#<wbr>L51</a>
<br>- This is an example I wrote...
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br>Okay, appearently its not that uncommon. But its =
seems mostly for high-levelish work that could be worked around if necessar=
y. In case of file-IO, its pretty low level and basic, and imposes a restri=
ction that cannot be worked around (=3D rebuild funcionality manually) in a=
ny way. Its kind of like if memcpy, memcmp etc... requires the end of the d=
ata-pointers passed in to contain a certain escape-sequence. <br><br>I&#39;=
ll rest my case though and hope that some other solution like the ones ment=
ioned are proposed - though as I said I personally didn&#39;t feel that CSt=
ringView/ZStringView worked out quite as well as expected, it just pushed t=
he burden of constructing the temporary-string further up to the user of th=
e abstractions instead of the abstaction itself. Might revisit it once I&#3=
9;m done porting the whole codebase to StringView though.<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/615c471b-87aa-4a9b-a006-b9612965d6e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/615c471b-87aa-4a9b-a006-b9612965d6e3=
%40isocpp.org</a>.<br />

------=_Part_2350_945262346.1502468869101--

------=_Part_2349_822363178.1502468869100--

.

On sexta-feira, 11 de agosto de 2017 02:16:19 PDT Olaf van der Spek wrote:
> > The requirement in order to provide defined behaviour that the character
> > after the view must be readable is publicly documented.
>
> Ouch. IMO that's not a reasonable requirement / interface.
>
> > Failure by the end
> > user to ensure this leads to UB, specifically, a segfault.
>
> What could the committee do about this?

Why should the committee do something about it?

 void *ptr = mmap(nullptr, 4096, PROT_READ, MAP_PRIVATE | MAP_ANON, -1, 0);
 std::string_view(static_cast<char *>(ptr), 4096);

The character after the end of the string is not readable. Why do you want me
to have 100% overhead?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/8213093.ESMYL9sCCc%40tjmaciei-mobl1.

.

On sexta-feira, 11 de agosto de 2017 02:20:30 PDT Olaf van der Spek wrote:
> What's the proper design for such interfaces though?
> zstring_view seems best but doesn't exist.
> const char* wouldn't do any unnecessary allocations.
> Both string_view and string might do unnecessary allocations

zstring_view would be a nice wrapper for const char*. It basically *is* a
const char*, with a nice string_view-like API on top.

> What do kernels use internally? If they use ptr/size there might be a
> chance for a ptr/size interface, if they don't we're stuck with
> termination.

Null-terminated strings. Both the Linux and Darwin/FreeBSD kernels are written
in C, so that use is very widespread. I don't know what the Windows kernel is
written in, but considering its age I doubt it's anything besides C.

Win32 may have some ptr/size string APIs, like MultiByteToWideChar, but I
don't remember ever seeing one such where file paths are concerned.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/3456831.gsseCm4DuK%40tjmaciei-mobl1.

.

------=_Part_2292_1433925503.1502470888487
Content-Type: multipart/alternative;
 boundary="----=_Part_2293_1369296512.1502470888487"

------=_Part_2293_1369296512.1502470888487
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 12:39:28 PM UTC-4, Thiago Macieira wrote:
>
> On sexta-feira, 11 de agosto de 2017 02:20:30 PDT Olaf van der Spek wrote:
> > What's the proper design for such interfaces though?
> > zstring_view seems best but doesn't exist.
> > const char* wouldn't do any unnecessary allocations.
> > Both string_view and string might do unnecessary allocations
>
> zstring_view would be a nice wrapper for const char*. It basically *is* a
> const char*, with a nice string_view-like API on top.
>

At present, there are essentially two designs for such a type, which I will
name differently based on actual code I've seen.

`zstring_view` is conceptually a `string_view`. This means that it is a
pointer+size, so `size()` is always O(1). But this also means that if you
try to put a literal in a `zstring_view`, it will have to invoke
`char_traits::length` to get the length. This is good if you're actually
going to use begin/end iterator pairs. But it's painful if you're just
doing one-time forward iteration.

`cstring_view` is just a `const char*` with a nice wrapper. It is just a
pointer, which means `size()` is always O(n). But this also means that
sticking a literal in it costs nothing. But if you try to use it with
begin/end iterator pairs, you provoke an O(n) operation.

At the same time, with the new Range TS paradigm of "iterator/sentinel"s,
it becomes possible to do forward iteration on a `cstring_view` without
that extra cost. The sentinel would simply dereference the iterator when it
does a comparison.

In the absence of the Range TS, I think `zstring_view` is the better
design. You can even mitigate the O(n) length for literals by providing a
`zsv` UDL for it (which I have in my implementation). But in the Range TS
world, where `cstring_view::end` can return a sentinel rather than an
iterator, `cstring_view` seems more performance-friendly in the common
cases of forward iteration.

The one thing I absolutely do not want is to *have both* of them
standardized. In the domain of NUL-terminated-string-views, we only need
one answer. And neither answer is so performance-unfriendly that the other
one needs to be standardized to fix it.

We could of course cop out, and simply say that when it invokes `length` is
implementation defined. In that case, `size()` may or may not be O(1). But
I *really* hate that idea.

--
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/6240d6af-a518-4788-a56f-b7d0c8976dc4%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 12:39:28 PM UTC-4, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-feira, 1=
1 de agosto de 2017 02:20:30 PDT Olaf van der Spek wrote:
<br>&gt; What&#39;s the proper design for such interfaces though?
<br>&gt; zstring_view seems best but doesn&#39;t exist.
<br>&gt; const char* wouldn&#39;t do any unnecessary allocations.
<br>&gt; Both string_view and string might do unnecessary allocations
<br>
<br>zstring_view would be a nice wrapper for const char*. It basically *is*=
 a=20
<br>const char*, with a nice string_view-like API on top.<br></blockquote><=
div><br>At present, there are essentially two designs for such a type, whic=
h I will name differently based on actual code I&#39;ve seen.<br><br>`zstri=
ng_view` is conceptually a `string_view`. This means that it is a pointer+s=
ize, so `size()` is always O(1). But this also means that if you try to put=
 a literal in a `zstring_view`, it will have to invoke `char_traits::length=
` to get the length. This is good if you&#39;re actually going to use begin=
/end iterator pairs. But it&#39;s painful if you&#39;re just doing one-time=
 forward iteration.<br><br>`cstring_view` is just a `const char*` with a ni=
ce wrapper. It is just a pointer, which means `size()` is always O(n). But =
this also means that sticking a literal in it costs nothing. But if you try=
 to use it with begin/end iterator pairs, you provoke an O(n) operation.<br=
><br>At the same time, with the new Range TS paradigm of &quot;iterator/sen=
tinel&quot;s, it becomes possible to do forward iteration on a `cstring_vie=
w` without that extra cost. The sentinel would simply dereference the itera=
tor when it does a comparison.<br><br>In the absence of the Range TS, I thi=
nk `zstring_view` is the better design. You can even mitigate the O(n) leng=
th for literals by providing a `zsv` UDL for it (which I have in my impleme=
ntation). But in the Range TS world, where `cstring_view::end` can return a=
 sentinel rather than an iterator, `cstring_view` seems more performance-fr=
iendly in the common cases of forward iteration.<br><br>The one thing I abs=
olutely do not want is to <i>have both</i> of them standardized. In the dom=
ain of NUL-terminated-string-views, we only need one answer. And neither an=
swer is so performance-unfriendly that the other one needs to be standardiz=
ed to fix it.<br><br>We could of course cop out, and simply say that when i=
t invokes `length` is implementation defined. In that case, `size()` may or=
 may not be O(1). But I <i>really</i> hate that idea.</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/6240d6af-a518-4788-a56f-b7d0c8976dc4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6240d6af-a518-4788-a56f-b7d0c8976dc4=
%40isocpp.org</a>.<br />

------=_Part_2293_1369296512.1502470888487--

------=_Part_2292_1433925503.1502470888487--

.

------=_Part_2200_569300886.1502470917285
Content-Type: multipart/alternative;
 boundary="----=_Part_2201_1385407254.1502470917285"

------=_Part_2201_1385407254.1502470917285
Content-Type: text/plain; charset="UTF-8"


>
>
> SG1 spent a lot of time on that when designing the C++11 threading
> library, and couldn't find a way to make POSIX cancellation fit into
> C++. You're welcome to spend more of your own time thinking about it,
> but there's unlikely to be a fit.
>
> Boost.Thread is probably as close as is possible to implement a thread
cancelling capable C++ 11 threading library. It has a lot of imperfections
and flaws. I think WG21 was right to leave out thread cancellation from the
standard threading library. If people think they really need thread
cancellation, they can go swap in Boost.Thread, it's mostly API compatible.

Niall

--
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/33a19ece-f2f8-454d-8983-918bfd6a8590%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>SG1 spent=
 a lot of time on that when designing the C++11 threading
<br>library, and couldn&#39;t find a way to make POSIX cancellation fit int=
o
<br>C++. You&#39;re welcome to spend more of your own time thinking about i=
t,
<br>but there&#39;s unlikely to be a fit.
<br><br></blockquote><div>Boost.Thread is probably as close as is possible =
to implement a thread cancelling capable C++ 11 threading library. It has a=
 lot of imperfections and flaws. I think WG21 was right to leave out thread=
 cancellation from the standard threading library. If people think they rea=
lly need thread cancellation, they can go swap in Boost.Thread, it&#39;s mo=
stly API compatible.</div><div><br></div><div>Niall</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/33a19ece-f2f8-454d-8983-918bfd6a8590%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/33a19ece-f2f8-454d-8983-918bfd6a8590=
%40isocpp.org</a>.<br />

------=_Part_2201_1385407254.1502470917285--

------=_Part_2200_569300886.1502470917285--

.

------=_Part_2206_1484980637.1502471449715
Content-Type: multipart/alternative;
 boundary="----=_Part_2207_1384850400.1502471449715"

------=_Part_2207_1384850400.1502471449715
Content-Type: text/plain; charset="UTF-8"


>
> > The requirement in order to provide defined behaviour that the character
> > after the view must be readable is publicly documented.
>
> Ouch. IMO that's not a reasonable requirement / interface.
>

Maybe not for string_view.

For a path_view, definitely yes. When have you ever sent a range of bytes
to a filesystem path API where accessing the character off the end of the
last non-zero character isn't legal?

I've been working on AFIO for a very long time now. I've never seen a case
in all my years.


>
> > Failure by the end
> > user to ensure this leads to UB, specifically, a segfault.
>
> What could the committee do about this?
>
> I've always felt that string_view could store whether the input at
construction is known for a fact to be zero terminated. Top bit of the
length would make sense. Maximum view size would then be SIZE_T_MAX>>1.

There is also a case that most of the string_view constructors could be
allowed to probe for zero termination after the view end, but at least one
constructor would be guaranteed to never do so.

Lots of options there. Finally, you could just leave string_view alone, and
adopt the afio::path_view instead. Filesystem paths are not like other zero
terminated strings sent to the kernel. They are treated as blobs of
undifferentiated bytes apart from zero and '/'.

Niall

--
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/62de958d-0a60-4477-aa10-54e7e3db7918%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; The requ=
irement in order to provide defined behaviour that the character
<br>&gt; after the view must be readable is publicly documented.
<br>
<br>Ouch. IMO that&#39;s not a reasonable requirement / interface.
<br></blockquote><div><br></div><div>Maybe not for string_view.</div><div><=
br></div><div>For a path_view, definitely yes. When have you ever sent a ra=
nge of bytes to a filesystem path API where accessing the character off the=
 end of the last non-zero character isn&#39;t legal?</div><div><br></div><d=
iv>I&#39;ve been working on AFIO for a very long time now. I&#39;ve never s=
een a case in all my years.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">
<br>&gt; Failure by the end
<br>&gt; user to ensure this leads to UB, specifically, a segfault.
<br>
<br>What could the committee do about this?
<br>
<br></blockquote><div>I&#39;ve always felt that string_view could store whe=
ther the input at construction is known for a fact to be zero terminated. T=
op bit of the length would make sense. Maximum view size would then be SIZE=
_T_MAX&gt;&gt;1.</div><div><br></div><div>There is also a case that most of=
 the string_view constructors could be allowed to probe for zero terminatio=
n after the view end, but at least one constructor would be guaranteed to n=
ever do so.</div><div><br></div><div>Lots of options there. Finally, you co=
uld just leave string_view alone, and adopt the afio::path_view instead. Fi=
lesystem paths are not like other zero terminated strings sent to the kerne=
l. They are treated as blobs of undifferentiated bytes apart from zero and =
&#39;/&#39;.</div><div><br></div><div>Niall</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/62de958d-0a60-4477-aa10-54e7e3db7918%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/62de958d-0a60-4477-aa10-54e7e3db7918=
%40isocpp.org</a>.<br />

------=_Part_2207_1384850400.1502471449715--

------=_Part_2206_1484980637.1502471449715--

.

------=_Part_2308_1826989305.1502471852642
Content-Type: multipart/alternative;
 boundary="----=_Part_2309_1785677967.1502471852642"

------=_Part_2309_1785677967.1502471852642
Content-Type: text/plain; charset="UTF-8"


>
>
> > What do kernels use internally? If they use ptr/size there might be a
> > chance for a ptr/size interface, if they don't we're stuck with
> > termination.
>
> Null-terminated strings. Both the Linux and Darwin/FreeBSD kernels are
> written
> in C, so that use is very widespread. I don't know what the Windows kernel
> is
> written in, but considering its age I doubt it's anything besides C.
>
> The NT kernel works in entirely in wchar_t with sized strings which cannot
exceed 65536 bytes. There are Length and MaximumLength fields, the latter
by tradition includes a zero terminator even though the kernel doesn't use
zero termination.

It is legal to supply strings containing one or many zero characters, they
are a legal filename. This causes much fun with Win32, and is a classic way
for virus authors to create undeleteable files.

Niall

--
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/62edcb4d-e186-4697-8b3d-a024ae73d2d5%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>&gt; What=
 do kernels use internally? If they use ptr/size there might be a
<br>&gt; chance for a ptr/size interface, if they don&#39;t we&#39;re stuck=
 with
<br>&gt; termination.
<br>
<br>Null-terminated strings. Both the Linux and Darwin/FreeBSD kernels are =
written=20
<br>in C, so that use is very widespread. I don&#39;t know what the Windows=
 kernel is=20
<br>written in, but considering its age I doubt it&#39;s anything besides C=
..
<br><br></blockquote><div>The NT kernel works in entirely in wchar_t with s=
ized strings which cannot exceed 65536 bytes. There are Length and MaximumL=
ength fields, the latter by tradition includes a zero terminator even thoug=
h the kernel doesn&#39;t use zero termination.</div><div><br></div><div>It =
is legal to supply strings containing one or many zero characters, they are=
 a legal filename. This causes much fun with Win32, and is a classic way fo=
r virus authors to create undeleteable files.</div><div><br></div><div>Nial=
l</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/62edcb4d-e186-4697-8b3d-a024ae73d2d5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/62edcb4d-e186-4697-8b3d-a024ae73d2d5=
%40isocpp.org</a>.<br />

------=_Part_2309_1785677967.1502471852642--

------=_Part_2308_1826989305.1502471852642--

.

------=_Part_2345_378367035.1502472085442
Content-Type: multipart/alternative;
 boundary="----=_Part_2346_1135322940.1502472085442"

------=_Part_2346_1135322940.1502472085442
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 6:01:28 PM UTC+1, Nicol Bolas wrote:
>
> On Friday, August 11, 2017 at 12:39:28 PM UTC-4, Thiago Macieira wrote:
>>
>> On sexta-feira, 11 de agosto de 2017 02:20:30 PDT Olaf van der Spek
>> wrote:
>> > What's the proper design for such interfaces though?
>>
>>
Let me ask a thought provoking question.

If you exclude filesystem paths, what remaining use cases are there for
zero terminated string views?

I'd argue not enough to bother standardising them, but maybe I've missed
something.

As for filesystem paths, they really are best implemented via a design
identical to afio::path_view. That design is optimally efficient on all
platforms.

Niall


--
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/01739e89-fc83-428b-94d5-e4e06927cc80%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 6:01:28 PM UTC+1, Nicol Bola=
s 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 Fr=
iday, August 11, 2017 at 12:39:28 PM UTC-4, Thiago Macieira wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On sexta-feira, 11 de agosto de 2017 02:20:3=
0 PDT Olaf van der Spek wrote:
<br>&gt; What&#39;s the proper design for such interfaces though?
<br><br></blockquote></div></blockquote><div><br></div><div>Let me ask a th=
ought provoking question.</div><div><br></div><div>If you exclude filesyste=
m paths, what remaining use cases are there for zero terminated string view=
s?</div><div><br></div><div>I&#39;d argue not enough to bother standardisin=
g them, but maybe I&#39;ve missed something.</div><div><br></div><div>As fo=
r filesystem paths, they really are best implemented via a design identical=
 to afio::path_view. That design is optimally efficient on all platforms.</=
div><div><br></div><div>Niall</div><div>=C2=A0</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/01739e89-fc83-428b-94d5-e4e06927cc80%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/01739e89-fc83-428b-94d5-e4e06927cc80=
%40isocpp.org</a>.<br />

------=_Part_2346_1135322940.1502472085442--

------=_Part_2345_378367035.1502472085442--

.

2017-08-11 18:34 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> On sexta-feira, 11 de agosto de 2017 02:16:19 PDT Olaf van der Spek wrote:
>> > The requirement in order to provide defined behaviour that the character
>> > after the view must be readable is publicly documented.
>>
>> Ouch. IMO that's not a reasonable requirement / interface.
>>
>> > Failure by the end
>> > user to ensure this leads to UB, specifically, a segfault.
>>
>> What could the committee do about this?
>
> Why should the committee do something about it?

I don't know..
Niall suggested the committee could do something about it so I'm
wondering what it is they could do.

>         void *ptr = mmap(nullptr, 4096, PROT_READ, MAP_PRIVATE | MAP_ANON, -1, 0);
>         std::string_view(static_cast<char *>(ptr), 4096);
>
> The character after the end of the string is not readable. Why do you want me
> to have 100% overhead?

I don't
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HP4tfei7whDNuHJDgvwQpe7z-DNQHNSJaqV%2BY%2BbfSThnQ%40mail.gmail.com.

.

------=_Part_2358_103070569.1502473094032
Content-Type: multipart/alternative;
 boundary="----=_Part_2359_1852950420.1502473094032"

------=_Part_2359_1852950420.1502473094032
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 1:21:25 PM UTC-4, Niall Douglas wrote:
>
> On Friday, August 11, 2017 at 6:01:28 PM UTC+1, Nicol Bolas wrote:
>>
>> On Friday, August 11, 2017 at 12:39:28 PM UTC-4, Thiago Macieira wrote:
>>>
>>> On sexta-feira, 11 de agosto de 2017 02:20:30 PDT Olaf van der Spek
>>> wrote:
>>> > What's the proper design for such interfaces though?
>>>
>>>
> Let me ask a thought provoking question.
>
> If you exclude filesystem paths, what remaining use cases are there for
> zero terminated string views?
>

Literally *any API* not under your direct control which exclusively
trafficks in NUL-terminated strings. It turns out there are a lot of those.
You can claim that maybe they shouldn't exist, but since those APIs are out
of your direct control, your desires mean squat.

The APIs are what they are, and you have to deal with them. And having a
single tool to deal with them is not a bad idea.

I'd argue not enough to bother standardising them, but maybe I've missed
> something.
>
> As for filesystem paths, they really are best implemented via a design
> identical to afio::path_view. That design is optimally efficient on all
> platforms.
>

Um... why? We already have a path type. And that path type is just a string
(of an implementation-defined type). So you can already get an appropriate
view for it. What's the point of having yet another view of a contiguous
sequence of constant characters?

--
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/c779961a-2aa5-437f-994e-d7df2573e8f5%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 1:21:25 PM UTC-4, Niall Doug=
las 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 =
Friday, August 11, 2017 at 6:01:28 PM UTC+1, Nicol Bolas 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 Friday, August 11, 2017 at =
12:39:28 PM UTC-4, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">On sexta-feira, 11 de agosto de 2017 02:20:30 PDT Olaf van der Spek w=
rote:
<br>&gt; What&#39;s the proper design for such interfaces though?
<br><br></blockquote></div></blockquote><div><br></div><div>Let me ask a th=
ought provoking question.</div><div><br></div><div>If you exclude filesyste=
m paths, what remaining use cases are there for zero terminated string view=
s?</div></div></blockquote><div><br>Literally <i>any API</i> not under your=
 direct control which exclusively trafficks in NUL-terminated strings. It t=
urns out there are a lot of those. You can claim that maybe they shouldn&#3=
9;t exist, but since those APIs are out of your direct control, your desire=
s mean squat.<br><br>The APIs are what they are, and you have to deal with =
them. And having a single tool to deal with them is not a bad idea.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></=
div><div>I&#39;d argue not enough to bother standardising them, but maybe I=
&#39;ve missed something.</div><div><br></div><div>As for filesystem paths,=
 they really are best implemented via a design identical to afio::path_view=
.. That design is optimally efficient on all platforms.</div></div></blockqu=
ote><div><br>Um... why? We already have a path type. And that path type is =
just a string (of an implementation-defined type). So you can already get a=
n appropriate view for it. What&#39;s the point of having yet another view =
of a contiguous sequence of constant characters?<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/c779961a-2aa5-437f-994e-d7df2573e8f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c779961a-2aa5-437f-994e-d7df2573e8f5=
%40isocpp.org</a>.<br />

------=_Part_2359_1852950420.1502473094032--

------=_Part_2358_103070569.1502473094032--

.

On Fri, Aug 11, 2017 at 10:38 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, August 11, 2017 at 1:21:25 PM UTC-4, Niall Douglas wrote:
>>
>> On Friday, August 11, 2017 at 6:01:28 PM UTC+1, Nicol Bolas wrote:
>>>
>>> On Friday, August 11, 2017 at 12:39:28 PM UTC-4, Thiago Macieira wrote:
>>>>
>>>> On sexta-feira, 11 de agosto de 2017 02:20:30 PDT Olaf van der Spek
>>>> wrote:
>>>> > What's the proper design for such interfaces though?
>>>>
>>
>> Let me ask a thought provoking question.
>>
>> If you exclude filesystem paths, what remaining use cases are there for
>> zero terminated string views?
>
>
> Literally any API not under your direct control which exclusively trafficks
> in NUL-terminated strings. It turns out there are a lot of those. You can
> claim that maybe they shouldn't exist, but since those APIs are out of your
> direct control, your desires mean squat.
>
> The APIs are what they are, and you have to deal with them. And having a
> single tool to deal with them is not a bad idea.

The standard's choices have an effect on how APIs evolve. If we think
folks should be migrating away from NUL-termination, omitting a
standard mechanism to deal with those APIs creates pressure to fix
them.

Jeffrey

--
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/CANh-dXnktuGkV61WuPFcgKJ%2B_F63OmxpW-r6xcUKzdd6W2uzRQ%40mail.gmail.com.

.

--94eb2c0ccb2e3bb6dc05567e2f74
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 11, 2017 at 1:02 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> The standard's choices have an effect on how APIs evolve. If we think
> folks should be migrating away from NUL-termination, omitting a
> standard mechanism to deal with those APIs creates pressure to fix
> them.
>

Many of those APIs are C, not C++, so I don't think our choices have much
weight with them.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNnTpXLW6V11Fxs1c%2BeQTz1wgJ2aP5h0Jp0Uka0eYeorw%40mail.gmail.com.

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

<div dir=3D"ltr">On Fri, Aug 11, 2017 at 1:02 PM, &#39;Jeffrey Yasskin&#39;=
 via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org<=
/a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">The standard&#39;s choices have an effec=
t on how APIs evolve. If we think<br>
folks should be migrating away from NUL-termination, omitting a<br>
standard mechanism to deal with those APIs creates pressure to fix<br>
them.<br></blockquote><div><br></div><div>Many of those APIs are C, not C++=
, so I don&#39;t think our choices have much weight with them.</div></div>-=
- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><di=
v dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=
=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div></=
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/CAGg_6%2BNnTpXLW6V11Fxs1c%2BeQTz1wgJ2=
aP5h0Jp0Uka0eYeorw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNnTp=
XLW6V11Fxs1c%2BeQTz1wgJ2aP5h0Jp0Uka0eYeorw%40mail.gmail.com</a>.<br />

--94eb2c0ccb2e3bb6dc05567e2f74--

.

------=_Part_2423_1288273193.1502475074913
Content-Type: multipart/alternative;
 boundary="----=_Part_2424_32795975.1502475074913"

------=_Part_2424_32795975.1502475074913
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 2:02:37 PM UTC-4, Jeffrey Yasskin wrote:
>
> On Fri, Aug 11, 2017 at 10:38 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > On Friday, August 11, 2017 at 1:21:25 PM UTC-4, Niall Douglas wrote:
> >>
> >> On Friday, August 11, 2017 at 6:01:28 PM UTC+1, Nicol Bolas wrote:
> >>>
> >>> On Friday, August 11, 2017 at 12:39:28 PM UTC-4, Thiago Macieira
> wrote:
> >>>>
> >>>> On sexta-feira, 11 de agosto de 2017 02:20:30 PDT Olaf van der Spek
> >>>> wrote:
> >>>> > What's the proper design for such interfaces though?
> >>>>
> >>
> >> Let me ask a thought provoking question.
> >>
> >> If you exclude filesystem paths, what remaining use cases are there for
> >> zero terminated string views?
> >
> >
> > Literally any API not under your direct control which exclusively
> trafficks
> > in NUL-terminated strings. It turns out there are a lot of those. You
> can
> > claim that maybe they shouldn't exist, but since those APIs are out of
> your
> > direct control, your desires mean squat.
> >
> > The APIs are what they are, and you have to deal with them. And having a
> > single tool to deal with them is not a bad idea.
>
> The standard's choices have an effect on how APIs evolve. If we think
> folks should be migrating away from NUL-termination, omitting a
> standard mechanism to deal with those APIs creates pressure to fix
> them.
>

We have to deal with the reality we have, not the reality we want.
`string_view` exists primarily because it has become abundantly clear that
the C++ world will not adopt a single, unified string type that everyone
will use. So instead of pretending that we can force everyone to adopt
`basic_string`, we instead shift towards allowing them to use their own
string types, with a decent intermediary view type that can be used for
intercommunication.

The C world is not going to adopt a string+size interface. Not uniformly.
WG14 is not going to create a bunch of `printf` alternatives that take
string+size rather than a NUL-terminated string. So we can either keep
hoping that they will eventually see the light, or we can bend to reality
and work with what we've got.

I prefer accepting reality.

--
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/bdaf405b-f2d2-4fd7-8bbd-5d6ef8f889b4%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 2:02:37 PM UTC-4, Jeffrey Ya=
sskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Aug 11, 20=
17 at 10:38 AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"zXNzEOHSBwAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;java=
script:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; On Friday, August 11, 2017 at 1:21:25 PM UTC-4, Niall Douglas wrot=
e:
<br>&gt;&gt;
<br>&gt;&gt; On Friday, August 11, 2017 at 6:01:28 PM UTC+1, Nicol Bolas wr=
ote:
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; On Friday, August 11, 2017 at 12:39:28 PM UTC-4, Thiago Ma=
cieira wrote:
<br>&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt; On sexta-feira, 11 de agosto de 2017 02:20:30 PDT Olaf=
 van der Spek
<br>&gt;&gt;&gt;&gt; wrote:
<br>&gt;&gt;&gt;&gt; &gt; What&#39;s the proper design for such interfaces =
though?
<br>&gt;&gt;&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Let me ask a thought provoking question.
<br>&gt;&gt;
<br>&gt;&gt; If you exclude filesystem paths, what remaining use cases are =
there for
<br>&gt;&gt; zero terminated string views?
<br>&gt;
<br>&gt;
<br>&gt; Literally any API not under your direct control which exclusively =
trafficks
<br>&gt; in NUL-terminated strings. It turns out there are a lot of those. =
You can
<br>&gt; claim that maybe they shouldn&#39;t exist, but since those APIs ar=
e out of your
<br>&gt; direct control, your desires mean squat.
<br>&gt;
<br>&gt; The APIs are what they are, and you have to deal with them. And ha=
ving a
<br>&gt; single tool to deal with them is not a bad idea.
<br>
<br>The standard&#39;s choices have an effect on how APIs evolve. If we thi=
nk
<br>folks should be migrating away from NUL-termination, omitting a
<br>standard mechanism to deal with those APIs creates pressure to fix
<br>them.
<br></blockquote><div><br>We have to deal with the reality we have, not the=
 reality we want. `string_view` exists primarily because it has become abun=
dantly clear that the C++ world will not adopt a single, unified string typ=
e that everyone will use. So instead of pretending that we can force everyo=
ne to adopt `basic_string`, we instead shift towards allowing them to use t=
heir own string types, with a decent intermediary view type that can be use=
d for intercommunication.<br><br>The C world is not going to adopt a string=
+size interface. Not uniformly. WG14 is not going to create a bunch of `pri=
ntf` alternatives that take string+size rather than a NUL-terminated string=
.. So we can either keep hoping that they will eventually see the light, or =
we can bend to reality and work with what we&#39;ve got.<br><br>I prefer ac=
cepting reality.<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/bdaf405b-f2d2-4fd7-8bbd-5d6ef8f889b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bdaf405b-f2d2-4fd7-8bbd-5d6ef8f889b4=
%40isocpp.org</a>.<br />

------=_Part_2424_32795975.1502475074913--

------=_Part_2423_1288273193.1502475074913--

.

On sexta-feira, 11 de agosto de 2017 10:01:28 PDT Nicol Bolas wrote:
> `zstring_view` is conceptually a `string_view`. This means that it is a
> pointer+size, so `size()` is always O(1). But this also means that if you
> try to put a literal in a `zstring_view`, it will have to invoke
> `char_traits::length` to get the length. This is good if you're actually
> going to use begin/end iterator pairs. But it's painful if you're just
> doing one-time forward iteration.
>
> `cstring_view` is just a `const char*` with a nice wrapper. It is just a
> pointer, which means `size()` is always O(n). But this also means that
> sticking a literal in it costs nothing. But if you try to use it with
> begin/end iterator pairs, you provoke an O(n) operation.

int main(std::initializer_list<std::cstring_view>)

can be accomplished with a simple instruction inserted by the compiler at the
beginning of main(), whereas

int main(std::initializer_list<std::zstring_view>)

would be O(n) and require O(n) storage for n == argc.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/250415405.SNDfSfLC7e%40tjmaciei-mobl1.

.

On sexta-feira, 11 de agosto de 2017 11:02:14 PDT 'Jeffrey Yasskin' via ISO C+
+ Standard - Future Proposals wrote:
> The standard's choices have an effect on how APIs evolve. If we think
> folks should be migrating away from NUL-termination, omitting a
> standard mechanism to deal with those APIs creates pressure to fix
> them.

The standard's choices mean squat for those who are not using the standard.
Like all the C developers.

(for some of them, it could be even reverse psychology)

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/3069154.QTiP9QeIQ7%40tjmaciei-mobl1.

.

2017-08-11 19:10 GMT+02:00 Niall Douglas <nialldouglas14@gmail.com>:
>> > The requirement in order to provide defined behaviour that the character
>> > after the view must be readable is publicly documented.
>>
>> Ouch. IMO that's not a reasonable requirement / interface.
>
>
> Maybe not for string_view.
>
> For a path_view, definitely yes. When have you ever sent a range of bytes to
> a filesystem path API where accessing the character off the end of the last
> non-zero character isn't legal?

I don't think I have, but if the argument is stored in a container
that's not using sentinels.. then I think it'd be trivially possible
for that situation to occur.

>> What could the committee do about this?
>>
> I've always felt that string_view could store whether the input at
> construction is known for a fact to be zero terminated. Top bit of the
> length would make sense. Maximum view size would then be SIZE_T_MAX>>1.
>
> There is also a case that most of the string_view constructors could be
> allowed to probe for zero termination after the view end, but at least one
> constructor would be guaranteed to never do so.
>
> Lots of options there. Finally, you could just leave string_view alone, and
> adopt the afio::path_view instead. Filesystem paths are not like other zero
> terminated strings sent to the kernel. They are treated as blobs of
> undifferentiated bytes apart from zero and '/'.

But then you'd have the unreasonable requirement..


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HOoPsFrBtQ6JA%3Dow3n-vtzDckPPHbsm0YC0_NjPYsRJuQ%40mail.gmail.com.

.

On sexta-feira, 11 de agosto de 2017 10:17:32 PDT Niall Douglas wrote:
> It is legal to supply strings containing one or many zero characters, they
> are a legal filename. This causes much fun with Win32, and is a classic way
> for virus authors to create undeleteable files.

The transition from zero-terminated and explicit length is a source of many
bugs and security issues. I can think of more than one such attack in the last
10 years.

Like X.509 certificates for "google.com\000.attacker.com". Or URLs with %00 in
them.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1878628.z5dfyhrtMh%40tjmaciei-mobl1.

.

On 11 August 2017 at 21:13, Thiago Macieira <thiago@macieira.org> wrote:
> On sexta-feira, 11 de agosto de 2017 11:02:14 PDT 'Jeffrey Yasskin' via ISO C+
> + Standard - Future Proposals wrote:
>> The standard's choices have an effect on how APIs evolve. If we think
>> folks should be migrating away from NUL-termination, omitting a
>> standard mechanism to deal with those APIs creates pressure to fix
>> them.
>
> The standard's choices mean squat for those who are not using the standard.
> Like all the C developers.

It might be plausible for some C developers to add ptr+length
functions in order to play nice
with a string_view, or to play nice with non-terminated substrings.
Whether that set of developers
includes WG14 or any particular group is another matter. But having
said that, "playing nice with string_view"
is a poor reason not to add a view-type that requires zero-termination.

> (for some of them, it could be even reverse psychology)

Well, yes, in case we'd want to say "we are never going to add a
termination-requiring view, please amend
all your interfaces". The rest of it may still end up being reverse
psychology, but we cannot hold ourselves
hostage to people who have already decided not to listen to anything we say. :)

--
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/CAFk2RUankyubiPFRsEZTjQ1SwWROsePVA2osu46yaPYTkp8bsw%40mail.gmail.com.

.

On Fri, Aug 11, 2017 at 11:06 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On Fri, Aug 11, 2017 at 1:02 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> The standard's choices have an effect on how APIs evolve. If we think
>> folks should be migrating away from NUL-termination, omitting a
>> standard mechanism to deal with those APIs creates pressure to fix
>> them.
>
>
> Many of those APIs are C, not C++, so I don't think our choices have much
> weight with them.

It's possible that the folks designing C APIs are all actively hostile
to C++ users, but I think a lot of them do it for the ABI stability,
and actually want to accommodate callers from other languages.

But I don't have veto power over what goes into C++. If folks want to
propose a {z,c}string_view, we'll see how the committee feels about
it.

Jeffrey

--
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/CANh-dXndop6o4RMEmzHu3RD9BSY5xTY0o1MBA7TtBSoF8W2cAg%40mail.gmail.com.

.

On 11 August 2017 at 21:21, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> It's possible that the folks designing C APIs are all actively hostile

Probably not. Some of them are too busy to think all that much about
how to wrap their APIs into a higher-level language
of any kind, some just don't care for other reasons, some might not
really know how to do it optimally. None of those categories
are actively hostile.

> to C++ users, but I think a lot of them do it for the ABI stability,
> and actually want to accommodate callers from other languages.

Yep.

> But I don't have veto power over what goes into C++. If folks want to
> propose a {z,c}string_view, we'll see how the committee feels about
> it.


It's a facility that's obviously useful, but whether it's useful
enough to pass the committee scrutiny is hard to predict.
And that also depends on what that type does, exactly, like whether
and where/how it really requires zero-termination.

--
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/CAFk2RUYGHoHbsfUAefCq1fZj0x%2B6K6xQ4Tv__sYShdD_pJzXuQ%40mail.gmail.com.

.

------=_Part_2226_1153724885.1502478558852
Content-Type: multipart/alternative;
 boundary="----=_Part_2227_1641056724.1502478558852"

------=_Part_2227_1641056724.1502478558852
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 2:12:42 PM UTC-4, Thiago Macieira wrote:
>
> On sexta-feira, 11 de agosto de 2017 10:01:28 PDT Nicol Bolas wrote:
> > `zstring_view` is conceptually a `string_view`. This means that it is a
> > pointer+size, so `size()` is always O(1). But this also means that if
> you
> > try to put a literal in a `zstring_view`, it will have to invoke
> > `char_traits::length` to get the length. This is good if you're actually
> > going to use begin/end iterator pairs. But it's painful if you're just
> > doing one-time forward iteration.
> >
> > `cstring_view` is just a `const char*` with a nice wrapper. It is just a
> > pointer, which means `size()` is always O(n). But this also means that
> > sticking a literal in it costs nothing. But if you try to use it with
> > begin/end iterator pairs, you provoke an O(n) operation.
>
> int main(std::initializer_list<std::cstring_view>)
>
> can be accomplished with a simple instruction inserted by the compiler at
> the
> beginning of main(),


How, exactly? `cstring_view` would not be *required* to be implemented as
identical to `const char*`, after all. So there's no way to could guarantee
that the `argv` array would be equivalent to that.

Also, it's not exactly a motivational use case for the 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51add97a-3379-4b9e-9bd3-8972ed0e7636%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 2:12:42 PM UTC-4, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-feira, 11=
 de agosto de 2017 10:01:28 PDT Nicol Bolas wrote:
<br>&gt; `zstring_view` is conceptually a `string_view`. This means that it=
 is a
<br>&gt; pointer+size, so `size()` is always O(1). But this also means that=
 if you
<br>&gt; try to put a literal in a `zstring_view`, it will have to invoke
<br>&gt; `char_traits::length` to get the length. This is good if you&#39;r=
e actually
<br>&gt; going to use begin/end iterator pairs. But it&#39;s painful if you=
&#39;re just
<br>&gt; doing one-time forward iteration.
<br>&gt;=20
<br>&gt; `cstring_view` is just a `const char*` with a nice wrapper. It is =
just a
<br>&gt; pointer, which means `size()` is always O(n). But this also means =
that
<br>&gt; sticking a literal in it costs nothing. But if you try to use it w=
ith
<br>&gt; begin/end iterator pairs, you provoke an O(n) operation.
<br>
<br>int main(std::initializer_list&lt;<wbr>std::cstring_view&gt;)
<br>
<br>can be accomplished with a simple instruction inserted by the compiler =
at the=20
<br>beginning of main(),</blockquote><div><br>How, exactly? `cstring_view` =
would not be <i>required</i> to be implemented as identical to `const char*=
`, after all. So there&#39;s no way to could guarantee that the `argv` arra=
y would be equivalent to that.<br><br>Also, it&#39;s not exactly a motivati=
onal use case for the type.</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/51add97a-3379-4b9e-9bd3-8972ed0e7636%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/51add97a-3379-4b9e-9bd3-8972ed0e7636=
%40isocpp.org</a>.<br />

------=_Part_2227_1641056724.1502478558852--

------=_Part_2226_1153724885.1502478558852--

.

On sexta-feira, 11 de agosto de 2017 12:09:18 PDT Nicol Bolas wrote:
> > int main(std::initializer_list<std::cstring_view>)
> >
> > can be accomplished with a simple instruction inserted by the compiler at
> > the
> > beginning of main(),
>
> How, exactly? `cstring_view` would not be *required* to be implemented as
> identical to `const char*`, after all. So there's no way to could guarantee
> that the `argv` array would be equivalent to that.

"can be accomplished" depends of course on the implementation details. If it
is implemented as the simplest possibility (a simple const char*), then the
main function can be accomplished with a single instruction added.

> Also, it's not exactly a motivational use case for the type.

Indeed. There's also the point that main takes "char **" for a reason: both
the pointers and the arguments are modifiable. You can't do that with a view or
std::initializer_list.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/7828291.YcltzT31Yz%40tjmaciei-mobl1.

.

--94eb2c11972ad90aec05567f94b4
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 11, 2017 at 12:01 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> `zstring_view` is conceptually a `string_view`. This means that it is a
> pointer+size, so `size()` is always O(1). But this also means that if you
> try to put a literal in a `zstring_view`, it will have to invoke
> `char_traits::length` to get the length. This is good if you're actually
> going to use begin/end iterator pairs. But it's painful if you're just
> doing one-time forward iteration.
>

Is it really that painful in practice?  I would expect a compiler to
optimize the length call away for a zstring_view<char> taking a C-string
literal.

Non-literals where you don't know the size are likely more of a problem, in
that you might be turning a one-pass algorithm into a two-pass algorithm.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMXUEs0Z3mCvEKWXdUQMVsZWxxM1qQpmtXtVJp6P_7K8w%40mail.gmail.com.

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

<div dir=3D"ltr">On Fri, Aug 11, 2017 at 12:01 PM, Nicol Bolas <span dir=3D=
"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesso=
n@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>`zstr=
ing_view` is conceptually a `string_view`. This means that it is a pointer+=
size, so `size()` is always O(1). But this also means that if you try to pu=
t a literal in a `zstring_view`, it will have to invoke `char_traits::lengt=
h` to get the length. This is good if you&#39;re actually going to use begi=
n/end iterator pairs. But it&#39;s painful if you&#39;re just doing one-tim=
e forward iteration.<br></div></div></blockquote><div><br></div><div>Is it =
really that painful in practice?=C2=A0 I would expect a compiler to optimiz=
e the length call away for a zstring_view&lt;char&gt; taking a C-string lit=
eral.</div><div><br></div><div>Non-literals where you don&#39;t know the si=
ze are likely more of a problem, in that you might be turning a one-pass al=
gorithm into a two-pass algorithm.</div></div>-- <br><div class=3D"gmail_si=
gnature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=
=3D"ltr"><div>=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+1-847-691-1404</div></div></div></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/CAGg_6%2BMXUEs0Z3mCvEKWXdUQMVsZWxxM1q=
QpmtXtVJp6P_7K8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMXUEs0=
Z3mCvEKWXdUQMVsZWxxM1qQpmtXtVJp6P_7K8w%40mail.gmail.com</a>.<br />

--94eb2c11972ad90aec05567f94b4--

.

--94eb2c0befec44e0dd05567fc3b3
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 11, 2017 at 12:10 PM, Niall Douglas <nialldouglas14@gmail.com>
wrote:

> I've always felt that string_view could store whether the input at
> construction is known for a fact to be zero terminated. Top bit of the
> length would make sense. Maximum view size would then be SIZE_T_MAX>>1.
>

Ugh.  I've found that types which model "may or may not" (may or may not
own, may or may not be zero terminated, etc.) are very clunky and error
prone to use.  This is, for instance, one of the problems with raw
pointers, as you don't know whether or not some cleanup has to be performed
after you are done with it.

If you want to model something different than string_view, it should be a
different type.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPB_fHoELHUbVY7-PTMTib8f6Zx61UVhMhrAhQAwfKfVQ%40mail.gmail.com.

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

<div dir=3D"ltr">On Fri, Aug 11, 2017 at 12:10 PM, Niall Douglas <span dir=
=3D"ltr">&lt;<a href=3D"mailto:nialldouglas14@gmail.com" target=3D"_blank">=
nialldouglas14@gmail.com</a>&gt;</span> wrote:<div class=3D"gmail_extra"><d=
iv class=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"><d=
iv>I&#39;ve always felt that string_view could store whether the input at c=
onstruction is known for a fact to be zero terminated. Top bit of the lengt=
h would make sense. Maximum view size would then be SIZE_T_MAX&gt;&gt;1.</d=
iv></div></blockquote><div><br></div><div>Ugh.=C2=A0 I&#39;ve found that ty=
pes which model &quot;may or may not&quot; (may or may not own, may or may =
not be zero terminated, etc.) are very clunky and error prone to use.=C2=A0=
 This is, for instance, one of the problems with raw pointers, as you don&#=
39;t know whether or not some cleanup has to be performed after you are don=
e with it.</div><div><br></div><div>If you want to model something differen=
t than string_view, it should be a different type.</div></div>-- <br><div c=
lass=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr=
"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;ma=
ilto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evil=
overlord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div></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/CAGg_6%2BPB_fHoELHUbVY7-PTMTib8f6Zx61=
UVhMhrAhQAwfKfVQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPB_fHo=
ELHUbVY7-PTMTib8f6Zx61UVhMhrAhQAwfKfVQ%40mail.gmail.com</a>.<br />

--94eb2c0befec44e0dd05567fc3b3--

.

On sexta-feira, 11 de agosto de 2017 10:01:28 PDT Nicol Bolas wrote:
> `cstring_view` is just a `const char*` with a nice wrapper. It is just a
> pointer, which means `size()` is always O(n). But this also means that
> sticking a literal in it costs nothing. But if you try to use it with
> begin/end iterator pairs, you provoke an O(n) operation.

Actually, no. The end iterator can be a sentinel, such that the call to
cstring_view::end() is O(1).

It's std::distance(begin, end) that is O(n). And rbegin().

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/23479188.ocqGNj8Gyb%40tjmaciei-mobl1.

.

------=_Part_2469_876993217.1502484899621
Content-Type: multipart/alternative;
 boundary="----=_Part_2470_501504542.1502484899621"

------=_Part_2470_501504542.1502484899621
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 4:36:36 PM UTC-4, Thiago Macieira wrote:
>
> On sexta-feira, 11 de agosto de 2017 10:01:28 PDT Nicol Bolas wrote:
> > `cstring_view` is just a `const char*` with a nice wrapper. It is just a
> > pointer, which means `size()` is always O(n). But this also means that
> > sticking a literal in it costs nothing. But if you try to use it with
> > begin/end iterator pairs, you provoke an O(n) operation.
>
> Actually, no. The end iterator can be a sentinel, such that the call to
> cstring_view::end() is O(1).
>

A fact I mentioned later in that post, but one that relies on Ranges TS and
its range algorithms. In a pre-Ranges TS world, that's not an acceptable
implementation, since all of our current algorithms are based on iterator
pairs, not iterator/sentinels.

--
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/ef0ef4f3-b2bc-4867-9cde-4d3b15c97d1e%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 4:36:36 PM UTC-4, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-feira, 11=
 de agosto de 2017 10:01:28 PDT Nicol Bolas wrote:
<br>&gt; `cstring_view` is just a `const char*` with a nice wrapper. It is =
just a
<br>&gt; pointer, which means `size()` is always O(n). But this also means =
that
<br>&gt; sticking a literal in it costs nothing. But if you try to use it w=
ith
<br>&gt; begin/end iterator pairs, you provoke an O(n) operation.
<br>
<br>Actually, no. The end iterator can be a sentinel, such that the call to=
=20
<br>cstring_view::end() is O(1).
<br></blockquote><div><br>A fact I mentioned later in that post, but one th=
at relies on Ranges TS and its range algorithms. In a pre-Ranges TS world, =
that&#39;s not an acceptable implementation, since all of our current algor=
ithms are based on iterator pairs, not iterator/sentinels.</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/ef0ef4f3-b2bc-4867-9cde-4d3b15c97d1e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef0ef4f3-b2bc-4867-9cde-4d3b15c97d1e=
%40isocpp.org</a>.<br />

------=_Part_2470_501504542.1502484899621--

------=_Part_2469_876993217.1502484899621--

.

------=_Part_2566_951838246.1502485545485
Content-Type: multipart/alternative;
 boundary="----=_Part_2567_2052301002.1502485545485"

------=_Part_2567_2052301002.1502485545485
Content-Type: text/plain; charset="UTF-8"


>
>
>> Let me ask a thought provoking question.
>>
>> If you exclude filesystem paths, what remaining use cases are there for
>> zero terminated string views?
>>
>
> Literally *any API* not under your direct control which exclusively
> trafficks in NUL-terminated strings. It turns out there are a lot of those.
> You can claim that maybe they shouldn't exist, but since those APIs are out
> of your direct control, your desires mean squat.
>

I don't get how a zero terminated string view gives you any benefit there.

Just pass around null terminated const char * as the end consumer can only
consume that anyway, and it won't accept lengths supplied by you. Knowing
the valid extent gains you nothing over using a plain string_view.


>
> I'd argue not enough to bother standardising them, but maybe I've missed
>> something.
>>
>> As for filesystem paths, they really are best implemented via a design
>> identical to afio::path_view. That design is optimally efficient on all
>> platforms.
>>
>
> Um... why? We already have a path type. And that path type is just a
> string (of an implementation-defined type). So you can already get an
> appropriate view for it. What's the point of having yet another view of a
> contiguous sequence of constant characters?
>

Oh, lot and lots.

Back during the Boost.Filesystem peer reviews, the correct design for path
was contentious. One of the best designs not adopted was one where the
underlying storage is type erased and a UTF-8 appearance is presented
publicly. This came with the big benefit that portable Filesystem code
doesn't need #ifdefing string literals for non-ASCII characters. The
current design where path wraps some string implementation which varies was
the one which won out in the end, and given all the competing factors and
tradeoffs, I agree it was the least worst choice.

However a path view has a very different set of tradeoffs, and the one
which swung in favour of the Filesystem TS path design over the "Plan B"
design - mutability - is no longer a problem. So we can adopt the "Plan B"
underlying storage erasing design from the Boost peer review as the only
"mutable" functions available (a subset of filesystem::path's) merely
return new views of the original, retaining the type erasure of the
underlying representation.

This enables path_view to very nicely complement and extend "Plan A" path
with many of the conveniences that dropping the "Plan B" path design cost.
So the dimorphic designs give the best of both worlds, and tick both sets
of boxes. I'm very pleased with it, it took me a year of trying ideas out
to decide on it as it was one of the hardest of the post-Boost-peer-review
issues to tackle, but now it's decided I'm very sure it's the right choice.

The way you prepare a path_view for being fed to a syscall, in case you
didn't read the API docs, is that you construct a path_view::c_str object
like this:

path_view pv;
path_view::c_str zpath(pv);
open(zpath.buffer, ...);

The path_view::c_str structure is a PATH_MAX sized structure with
additional buffer and length values. If the source view is zero terminated,
that is used directly. If it is not, it is copied into the c_str and zero
terminated. If on Windows and the underlying view source is UTF-8, a
conversion to UTF-16 is done. It is perfectly minimum overhead, no malloc
anywwhere, and can be used by end users identically on Windows and POSIX,
no #ifdefing.

Niall

--
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/25b20004-c1b3-4844-b957-ef57e043b533%40isocpp.org.

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

<div dir=3D"ltr"><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"l=
tr"><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><br></div=
><div>Let me ask a thought provoking question.</div><div><br></div><div>If =
you exclude filesystem paths, what remaining use cases are there for zero t=
erminated string views?</div></div></blockquote><div><br>Literally <i>any A=
PI</i> not under your direct control which exclusively trafficks in NUL-ter=
minated strings. It turns out there are a lot of those. You can claim that =
maybe they shouldn&#39;t exist, but since those APIs are out of your direct=
 control, your desires mean squat.<br></div></div></blockquote><div><br></d=
iv><div>I don&#39;t get how a zero terminated string view gives you any ben=
efit there.</div><div><br></div><div>Just pass around null terminated const=
 char * as the end consumer can only consume that anyway, and it won&#39;t =
accept lengths supplied by you. Knowing the valid extent gains you nothing =
over using a plain string_view.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></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><div>I&#39;d argue not e=
nough to bother standardising them, but maybe I&#39;ve missed something.</d=
iv><div><br></div><div>As for filesystem paths, they really are best implem=
ented via a design identical to afio::path_view. That design is optimally e=
fficient on all platforms.</div></div></blockquote><div><br>Um... why? We a=
lready have a path type. And that path type is just a string (of an impleme=
ntation-defined type). So you can already get an appropriate view for it. W=
hat&#39;s the point of having yet another view of a contiguous sequence of =
constant characters?<br></div></div></blockquote><div><br></div><div>Oh, lo=
t and lots.</div><div><br></div><div>Back during the Boost.Filesystem peer =
reviews, the correct design for path was contentious. One of the best desig=
ns not adopted was one where the underlying storage is type erased and a UT=
F-8 appearance is presented publicly. This came with the big benefit that p=
ortable Filesystem code doesn&#39;t need #ifdefing string literals for non-=
ASCII characters. The current design where path wraps some string implement=
ation which varies was the one which won out in the end, and given all the =
competing factors and tradeoffs, I agree it was the least worst choice.</di=
v><div><br></div><div>However a path view has a very different set of trade=
offs, and the one which swung in favour of the Filesystem TS path design ov=
er the &quot;Plan B&quot; design - mutability - is no longer a problem. So =
we can adopt the &quot;Plan B&quot; underlying storage erasing design from =
the Boost peer review as the only &quot;mutable&quot; functions available (=
a subset of filesystem::path&#39;s) merely return new views of the original=
, retaining the type erasure of the underlying representation.</div><div><b=
r></div><div>This enables path_view to very nicely complement and extend &q=
uot;Plan A&quot; path with many of the conveniences that dropping the &quot=
;Plan B&quot; path design cost. So the dimorphic designs give the best of b=
oth worlds, and tick both sets of boxes. I&#39;m very pleased with it, it t=
ook me a year of trying ideas out to decide on it as it was one of the hard=
est of the post-Boost-peer-review issues to tackle, but now it&#39;s decide=
d I&#39;m very sure it&#39;s the right choice.</div><div><br></div><div>The=
 way you prepare a path_view for being fed to a syscall, in case you didn&#=
39;t read the API docs, is that you construct a path_view::c_str object lik=
e this:</div><div><br></div><div>path_view pv;</div><div>path_view::c_str z=
path(pv);</div><div>open(zpath.buffer, ...);</div><div><br></div><div>The p=
ath_view::c_str structure is a PATH_MAX sized structure with additional buf=
fer and length values. If the source view is zero terminated, that is used =
directly. If it is not, it is copied into the c_str and zero terminated. If=
 on Windows and the underlying view source is UTF-8, a conversion to UTF-16=
 is done. It is perfectly minimum overhead, no malloc anywwhere, and can be=
 used by end users identically on Windows and POSIX, no #ifdefing.</div><di=
v><br></div><div>Niall</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/25b20004-c1b3-4844-b957-ef57e043b533%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/25b20004-c1b3-4844-b957-ef57e043b533=
%40isocpp.org</a>.<br />

------=_Part_2567_2052301002.1502485545485--

------=_Part_2566_951838246.1502485545485--

.

On sexta-feira, 11 de agosto de 2017 14:05:45 PDT Niall Douglas wrote:
> path_view pv;
> path_view::c_str zpath(pv);
> open(zpath.buffer, ...);
>
> The path_view::c_str structure is a PATH_MAX sized structure with
> additional buffer and length values. If the source view is zero terminated,
> that is used directly. If it is not, it is copied into the c_str and zero
> terminated. If on Windows and the underlying view source is UTF-8, a
> conversion to UTF-16 is done. It is perfectly minimum overhead, no malloc
> anywwhere, and can be used by end users identically on Windows and POSIX,
> no #ifdefing.

So you're saying that it uses 64kB of stack on Windows?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1630708.cPAEmNVcRk%40tjmaciei-mobl1.

.

------=_Part_1878_638274701.1502486977752
Content-Type: multipart/alternative;
 boundary="----=_Part_1879_1912604382.1502486977752"

------=_Part_1879_1912604382.1502486977752
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 5:05:45 PM UTC-4, Niall Douglas wrote:
>
>
>>> Let me ask a thought provoking question.
>>>
>>> If you exclude filesystem paths, what remaining use cases are there for
>>> zero terminated string views?
>>>
>>
>> Literally *any API* not under your direct control which exclusively
>> trafficks in NUL-terminated strings. It turns out there are a lot of those.
>> You can claim that maybe they shouldn't exist, but since those APIs are out
>> of your direct control, your desires mean squat.
>>
>
> I don't get how a zero terminated string view gives you any benefit there.
>

It provides me the ability to write APIs that propagate the requirements I
have to the caller. Remember: most string types really are NUL-terminated.
Consider this case:

void some_func_fixed(const fixed_string<32> &str)
{
  needs_nul_terminated(str.data());
}

void some_func_view(string_view sv)
{
  std::string str(sv);
  needs_nul_terminated(str.data());
};

fixed_string<32> str;
some_func_fixed(sv);
some_func_view(sv);

As you can see, `fixed_string` is a NUL-terminated string, just like most
C++ string types. And yet, if you try to call `some_func_view`, it makes a
copy. Pointlessly.

`some_func_view` is flexible, since it can take any string you can get a
string_view out of. But it is bad because it makes a copy from a source
that is probably NUL-terminated.

`z/cstring_view` would give us the flexibility without the bad part.

Just pass around null terminated const char * as the end consumer can only
> consume that anyway, and it won't accept lengths supplied by you. Knowing
> the valid extent gains you nothing over using a plain string_view.
>
>
>>
>> I'd argue not enough to bother standardising them, but maybe I've missed
>>> something.
>>>
>>> As for filesystem paths, they really are best implemented via a design
>>> identical to afio::path_view. That design is optimally efficient on all
>>> platforms.
>>>
>>
>> Um... why? We already have a path type. And that path type is just a
>> string (of an implementation-defined type). So you can already get an
>> appropriate view for it. What's the point of having yet another view of a
>> contiguous sequence of constant characters?
>>
>
> Oh, lot and lots.
>
> Back during the Boost.Filesystem peer reviews, the correct design for path
> was contentious. One of the best designs not adopted was one where the
> underlying storage is type erased and a UTF-8 appearance is presented
> publicly. This came with the big benefit that portable Filesystem code
> doesn't need #ifdefing string literals for non-ASCII characters. The
> current design where path wraps some string implementation which varies was
> the one which won out in the end, and given all the competing factors and
> tradeoffs, I agree it was the least worst choice.
>
> However a path view has a very different set of tradeoffs, and the one
> which swung in favour of the Filesystem TS path design over the "Plan B"
> design - mutability - is no longer a problem. So we can adopt the "Plan B"
> underlying storage erasing design from the Boost peer review as the only
> "mutable" functions available (a subset of filesystem::path's) merely
> return new views of the original, retaining the type erasure of the
> underlying representation.
>

Or we can just have a single `filesystem::path` type, which you can get
views of with existing types. I prefer that option.

--
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/15b49197-b38b-47be-aefb-0786af7635f2%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 5:05:45 PM UTC-4, Niall Doug=
las 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"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><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><br></div><div>Let me ask a though=
t provoking question.</div><div><br></div><div>If you exclude filesystem pa=
ths, what remaining use cases are there for zero terminated string views?</=
div></div></blockquote><div><br>Literally <i>any API</i> not under your dir=
ect control which exclusively trafficks in NUL-terminated strings. It turns=
 out there are a lot of those. You can claim that maybe they shouldn&#39;t =
exist, but since those APIs are out of your direct control, your desires me=
an squat.<br></div></div></blockquote><div><br></div><div>I don&#39;t get h=
ow a zero terminated string view gives you any benefit there.</div></div></=
blockquote><div><br>It provides me the ability to write APIs that propagate=
 the requirements I have to the caller. Remember: most string types really =
are NUL-terminated. Consider this case:<br><br><div style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> some_func_fixed</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> fixed_string</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">32</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">str<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 needs_nul_terminated</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">str</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">data</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">());</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> some_func_view</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
tring_view sv</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> str</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">sv</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 needs_nul_terminated</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">str</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">data</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">());</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>fixed_=
string</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">32</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> str</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>some_func_fixed</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">sv</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>some_func_view</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">sv</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span></div></code></div><br>As you can see, `fixed_stri=
ng` is a NUL-terminated string, just like most C++ string types. And yet, i=
f you try to call `some_func_view`, it makes a copy. Pointlessly.<br><br>`s=
ome_func_view` is flexible, since it can take any string you can get a stri=
ng_view out of. But it is bad because it makes a copy from a source that is=
 probably NUL-terminated.<br><br>`z/cstring_view` would give us the flexibi=
lity without the bad part.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div></div><div>Just pass around null terminated=
 const char * as the end consumer can only consume that anyway, and it won&=
#39;t accept lengths supplied by you. Knowing the valid extent gains you no=
thing over using a plain string_view.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div><br></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><div>I&#39;d argue not e=
nough to bother standardising them, but maybe I&#39;ve missed something.</d=
iv><div><br></div><div>As for filesystem paths, they really are best implem=
ented via a design identical to afio::path_view. That design is optimally e=
fficient on all platforms.</div></div></blockquote><div><br>Um... why? We a=
lready have a path type. And that path type is just a string (of an impleme=
ntation-defined type). So you can already get an appropriate view for it. W=
hat&#39;s the point of having yet another view of a contiguous sequence of =
constant characters?<br></div></div></blockquote><div><br></div><div>Oh, lo=
t and lots.</div><div><br></div><div>Back during the Boost.Filesystem peer =
reviews, the correct design for path was contentious. One of the best desig=
ns not adopted was one where the underlying storage is type erased and a UT=
F-8 appearance is presented publicly. This came with the big benefit that p=
ortable Filesystem code doesn&#39;t need #ifdefing string literals for non-=
ASCII characters. The current design where path wraps some string implement=
ation which varies was the one which won out in the end, and given all the =
competing factors and tradeoffs, I agree it was the least worst choice.</di=
v><div><br></div><div>However a path view has a very different set of trade=
offs, and the one which swung in favour of the Filesystem TS path design ov=
er the &quot;Plan B&quot; design - mutability - is no longer a problem. So =
we can adopt the &quot;Plan B&quot; underlying storage erasing design from =
the Boost peer review as the only &quot;mutable&quot; functions available (=
a subset of filesystem::path&#39;s) merely return new views of the original=
, retaining the type erasure of the underlying representation.</div></div><=
/blockquote><div><br>Or we can just have a single `filesystem::path` type, =
which you can get views of with existing types. I prefer that option.</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/15b49197-b38b-47be-aefb-0786af7635f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/15b49197-b38b-47be-aefb-0786af7635f2=
%40isocpp.org</a>.<br />

------=_Part_1879_1912604382.1502486977752--

------=_Part_1878_638274701.1502486977752--

.

On sexta-feira, 11 de agosto de 2017 14:29:37 PDT Nicol Bolas wrote:
> As you can see, `fixed_string` is a NUL-terminated string, just like most
> C++ string types. And yet, if you try to call `some_func_view`, it makes a
> copy. Pointlessly.
>
> `some_func_view` is flexible, since it can take any string you can get a
> string_view out of. But it is bad because it makes a copy from a source
> that is probably NUL-terminated.

Hence Niall'srequirement in his API that the next byte be readable. That way,
the code can check if it is NUL-terminated and avoid the allocation.

It's a requirement that very rarely fails.

And if you know the ABI, you can also check if the byte load can cause a fault
or not. I use that in my update to Qt's QString/QByteArray hasher, so it may
load up to 15 bytes after the end of your string (it's x86-specific).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/4668992.qiGeeS5zhn%40tjmaciei-mobl1.

.

------=_Part_2519_1998246755.1502490372455
Content-Type: multipart/alternative;
 boundary="----=_Part_2520_1931980374.1502490372455"

------=_Part_2520_1931980374.1502490372455
Content-Type: text/plain; charset="UTF-8"


>
>
> > The path_view::c_str structure is a PATH_MAX sized structure with
> > additional buffer and length values. If the source view is zero
> terminated,
> > that is used directly. If it is not, it is copied into the c_str and
> zero
> > terminated. If on Windows and the underlying view source is UTF-8, a
> > conversion to UTF-16 is done. It is perfectly minimum overhead, no
> malloc
> > anywwhere, and can be used by end users identically on Windows and
> POSIX,
> > no #ifdefing.
>
> So you're saying that it uses 64kB of stack on Windows?
>

For now yes. And 32Kb on Linux and 1Kb on FreeBSD as those are their
PATH_MAX.

If it turns out to be a problem down the line, we could shrink to 4Kb and
use malloc if the input path is longer than that. For now I haven't
encountered a problem, generally if you're calling a path consuming
syscall, this is not an overhead.

Niall

--
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/8841975e-d2b4-49dd-8f31-f8d19bc0c56b%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>&gt; The =
path_view::c_str structure is a PATH_MAX sized structure with
<br>&gt; additional buffer and length values. If the source view is zero te=
rminated,
<br>&gt; that is used directly. If it is not, it is copied into the c_str a=
nd zero
<br>&gt; terminated. If on Windows and the underlying view source is UTF-8,=
 a
<br>&gt; conversion to UTF-16 is done. It is perfectly minimum overhead, no=
 malloc
<br>&gt; anywwhere, and can be used by end users identically on Windows and=
 POSIX,
<br>&gt; no #ifdefing.
<br>
<br>So you&#39;re saying that it uses 64kB of stack on Windows?
<br>
</blockquote><div><br></div><div>For now yes. And 32Kb on Linux and 1Kb on =
FreeBSD as those are their PATH_MAX.</div><div><br></div><div>If it turns o=
ut to be a problem down the line, we could shrink to 4Kb and use malloc if =
the input path is longer than that. For now I haven&#39;t encountered a pro=
blem, generally if you&#39;re calling a path consuming syscall, this is not=
 an overhead.</div><div><br></div><div>Niall</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/8841975e-d2b4-49dd-8f31-f8d19bc0c56b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8841975e-d2b4-49dd-8f31-f8d19bc0c56b=
%40isocpp.org</a>.<br />

------=_Part_2520_1931980374.1502490372455--

------=_Part_2519_1998246755.1502490372455--

.

------=_Part_2478_1398369499.1502490562918
Content-Type: multipart/alternative;
 boundary="----=_Part_2479_1598270752.1502490562918"

------=_Part_2479_1598270752.1502490562918
Content-Type: text/plain; charset="UTF-8"


>
>
> Or we can just have a single `filesystem::path` type, which you can get
> views of with existing types. I prefer that option.
>

As already covered in great detail by now, if fed a string_view then one is
mandated to memcpy the lot so it can be zero terminated before sending it
to the file path consuming syscall.

As much as open() is not a fast syscall, copying 32Kb needlessly makes a
statistically noticeable difference. path_view eliminates that problem.

Niall


--
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/188dc31c-df5e-4fe1-ad85-847d3d732880%40isocpp.org.

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

<div dir=3D"ltr"><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"l=
tr"><div><br>Or we can just have a single `filesystem::path` type, which yo=
u can get views of with existing types. I prefer that option.</div></div></=
blockquote><div><br></div><div>As already covered in great detail by now, i=
f fed a string_view then one is mandated to memcpy the lot so it can be zer=
o terminated before sending it to the file path consuming syscall.</div><di=
v><br></div><div>As much as open() is not a fast syscall, copying 32Kb need=
lessly makes a statistically noticeable difference. path_view eliminates th=
at problem.</div><div><br></div><div>Niall</div><div>=C2=A0</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/188dc31c-df5e-4fe1-ad85-847d3d732880%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/188dc31c-df5e-4fe1-ad85-847d3d732880=
%40isocpp.org</a>.<br />

------=_Part_2479_1598270752.1502490562918--

------=_Part_2478_1398369499.1502490562918--

.

------=_Part_2633_1135565494.1502491094158
Content-Type: multipart/alternative;
 boundary="----=_Part_2634_1625434601.1502491094159"

------=_Part_2634_1625434601.1502491094159
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 10:56:08 PM UTC+1, Thiago Macieira wrote:
>
> On sexta-feira, 11 de agosto de 2017 14:29:37 PDT Nicol Bolas wrote:
> > As you can see, `fixed_string` is a NUL-terminated string, just like
> most
> > C++ string types. And yet, if you try to call `some_func_view`, it makes
> a
> > copy. Pointlessly.
> >
> > `some_func_view` is flexible, since it can take any string you can get a
> > string_view out of. But it is bad because it makes a copy from a source
> > that is probably NUL-terminated.
>
> Hence Niall'srequirement in his API that the next byte be readable. That
> way,
> the code can check if it is NUL-terminated and avoid the allocation.
>
> It's a requirement that very rarely fails.
>

string_view already had to be extremely conservative because a string is so
overloaded with meaning in C++. We store all sorts of things into a char
array, often using std::string when std::vector<char> really would be more
appropriate. It's entirely legitimate to do mmap(4Kb) and pass that through
to other code via string_view. A span would be more appropriate, but that's
not into the standard yet.

Filesystem paths on the other hand are much more specific. You'll never do
mmap(4Kb) and wrap that into a path_view, or at least, if you did then wrap
4Kb-1 into a path_view and you'll be fine. But we can impose that
requirement precisely and only because we know the content. With
string_view you can't know what the content will mean, or form it will come
in.

With your zstring_view I appreciate your pain, and I indeed did argue for
null terminator support in string_view with Marshall back in the day. But
that ship has sailed, and the value add of a special zstring_view seems
very low to me when more specialised view-of-something-particular is the
obvious path forwards.

BTW people have tried to persuade WG14 to replace zero terminated strings
for as long as I can remember. Nobody has ever achieved it. Same goes for
POSIX. It's not for a lack of sympathy to the problem, it's that those
bodies only standardise existing practice where possible, and no
implementation apart from Windows NT ironically enough has ever broken with
null terminated strings. So it's a catch-22.

Niall

--
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/54ef3906-5fba-49e8-91ab-eff8be691b7d%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 10:56:08 PM UTC+1, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-feira, 1=
1 de agosto de 2017 14:29:37 PDT Nicol Bolas wrote:
<br>&gt; As you can see, `fixed_string` is a NUL-terminated string, just li=
ke most
<br>&gt; C++ string types. And yet, if you try to call `some_func_view`, it=
 makes a
<br>&gt; copy. Pointlessly.
<br>&gt;=20
<br>&gt; `some_func_view` is flexible, since it can take any string you can=
 get a
<br>&gt; string_view out of. But it is bad because it makes a copy from a s=
ource
<br>&gt; that is probably NUL-terminated.
<br>
<br>Hence Niall&#39;srequirement in his API that the next byte be readable.=
 That way,=20
<br>the code can check if it is NUL-terminated and avoid the allocation.
<br>
<br>It&#39;s a requirement that very rarely fails.
<br>
</blockquote><div><br></div><div>string_view already had to be extremely co=
nservative because a string is so overloaded with meaning in C++. We store =
all sorts of things into a char array, often using std::string when std::ve=
ctor&lt;char&gt; really would be more appropriate. It&#39;s entirely legiti=
mate to do mmap(4Kb) and pass that through to other code via string_view. A=
 span would be more appropriate, but that&#39;s not into the standard yet.<=
/div><div><br></div><div>Filesystem paths on the other hand are much more s=
pecific. You&#39;ll never do mmap(4Kb) and wrap that into a path_view, or a=
t least, if you did then wrap 4Kb-1 into a path_view and you&#39;ll be fine=
.. But we can impose that requirement precisely and only because we know the=
 content. With string_view you can&#39;t know what the content will mean, o=
r form it will come in.</div><div><br></div><div>With your zstring_view I a=
ppreciate your pain, and I indeed did argue for null terminator support in =
string_view with Marshall back in the day. But that ship has sailed, and th=
e value add of a special zstring_view seems very low to me when more specia=
lised view-of-something-particular is the obvious path forwards.</div><div>=
<br></div><div>BTW people have tried to persuade WG14 to replace zero termi=
nated strings for as long as I can remember. Nobody has ever achieved it. S=
ame goes for POSIX. It&#39;s not for a lack of sympathy to the problem, it&=
#39;s that those bodies only standardise existing practice where possible, =
and no implementation apart from Windows NT ironically enough has ever brok=
en with null terminated strings. So it&#39;s a catch-22.</div><div><br></di=
v><div>Niall</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/54ef3906-5fba-49e8-91ab-eff8be691b7d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/54ef3906-5fba-49e8-91ab-eff8be691b7d=
%40isocpp.org</a>.<br />

------=_Part_2634_1625434601.1502491094159--

------=_Part_2633_1135565494.1502491094158--

.

------=_Part_2564_389094282.1502491694795
Content-Type: multipart/alternative;
 boundary="----=_Part_2565_470656277.1502491694796"

------=_Part_2565_470656277.1502491694796
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 6:29:23 PM UTC-4, Niall Douglas wrote:
>
>
>> Or we can just have a single `filesystem::path` type, which you can get
>> views of with existing types. I prefer that option.
>>
>
> As already covered in great detail by now, if fed a string_view then one
> is mandated to memcpy the lot so it can be zero terminated before sending
> it to the file path consuming syscall.
>

A problem easily solved with the types we're talking about. We don't need a
replacement for `filesystem::path`. We *certainly* don't need some 32KB
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/586cd0e2-2fd9-4af0-814c-7ca19ecac410%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 6:29:23 PM UTC-4, Niall Doug=
las 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"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>Or we can ju=
st have a single `filesystem::path` type, which you can get views of with e=
xisting types. I prefer that option.</div></div></blockquote><div><br></div=
><div>As already covered in great detail by now, if fed a string_view then =
one is mandated to memcpy the lot so it can be zero terminated before sendi=
ng it to the file path consuming syscall.</div></div></blockquote><div><br>=
A problem easily solved with the types we&#39;re talking about. We don&#39;=
t need a replacement for `filesystem::path`. We <i>certainly</i> don&#39;t =
need some 32KB type...<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/586cd0e2-2fd9-4af0-814c-7ca19ecac410%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/586cd0e2-2fd9-4af0-814c-7ca19ecac410=
%40isocpp.org</a>.<br />

------=_Part_2565_470656277.1502491694796--

------=_Part_2564_389094282.1502491694795--

.

------=_Part_2621_2018591339.1502491824628
Content-Type: multipart/alternative;
 boundary="----=_Part_2622_1794295247.1502491824628"

------=_Part_2622_1794295247.1502491824628
Content-Type: text/plain; charset="UTF-8"



On Friday, August 11, 2017 at 5:56:08 PM UTC-4, Thiago Macieira wrote:
>
> On sexta-feira, 11 de agosto de 2017 14:29:37 PDT Nicol Bolas wrote:
> > As you can see, `fixed_string` is a NUL-terminated string, just like
> most
> > C++ string types. And yet, if you try to call `some_func_view`, it makes
> a
> > copy. Pointlessly.
> >
> > `some_func_view` is flexible, since it can take any string you can get a
> > string_view out of. But it is bad because it makes a copy from a source
> > that is probably NUL-terminated.
>
> Hence Niall'srequirement in his API that the next byte be readable. That
> way,
> the code can check if it is NUL-terminated and avoid the allocation.
>
> It's a requirement that very rarely fails.
>

It's also not a requirement that's part of the type system. Thus making it
even more fragile than an interface that just takes a naked `const char*`.
At least there, there is a long-standing tradition of expecting them be
NUL-terminated.

--
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/2eca4f0d-4f7b-4f16-b036-1e0eb1523aa9%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, August 11, 2017 at 5:56:08 PM UTC-4, Th=
iago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-f=
eira, 11 de agosto de 2017 14:29:37 PDT Nicol Bolas wrote:
<br>&gt; As you can see, `fixed_string` is a NUL-terminated string, just li=
ke most
<br>&gt; C++ string types. And yet, if you try to call `some_func_view`, it=
 makes a
<br>&gt; copy. Pointlessly.
<br>&gt;=20
<br>&gt; `some_func_view` is flexible, since it can take any string you can=
 get a
<br>&gt; string_view out of. But it is bad because it makes a copy from a s=
ource
<br>&gt; that is probably NUL-terminated.
<br>
<br>Hence Niall&#39;srequirement in his API that the next byte be readable.=
 That way,=20
<br>the code can check if it is NUL-terminated and avoid the allocation.
<br>
<br>It&#39;s a requirement that very rarely fails.<br></blockquote><div><br=
>It&#39;s also not a requirement that&#39;s part of the type system. Thus m=
aking it even more fragile than an interface that just takes a naked `const=
 char*`. At least there, there is a long-standing tradition of expecting th=
em be NUL-terminated.<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/2eca4f0d-4f7b-4f16-b036-1e0eb1523aa9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2eca4f0d-4f7b-4f16-b036-1e0eb1523aa9=
%40isocpp.org</a>.<br />

------=_Part_2622_1794295247.1502491824628--

------=_Part_2621_2018591339.1502491824628--

.

------=_Part_3052_1391438201.1502551424426
Content-Type: multipart/alternative;
 boundary="----=_Part_3053_1734689408.1502551424426"

------=_Part_3053_1734689408.1502551424426
Content-Type: text/plain; charset="UTF-8"

On Friday, August 11, 2017 at 11:48:14 PM UTC+1, Nicol Bolas wrote:
>
> On Friday, August 11, 2017 at 6:29:23 PM UTC-4, Niall Douglas wrote:
>>
>>
>>> Or we can just have a single `filesystem::path` type, which you can get
>>> views of with existing types. I prefer that option.
>>>
>>
>> As already covered in great detail by now, if fed a string_view then one
>> is mandated to memcpy the lot so it can be zero terminated before sending
>> it to the file path consuming syscall.
>>
>
> A problem easily solved with the types we're talking about. We don't need
> a replacement for `filesystem::path`. We *certainly* don't need some 32KB
> type...
>

I hate to be slightly rude, but you really don't know what you're talking
about on this.

Try doing some benchmarking of the actual cost of a potentially unused 64Kb
stack allocation in a routine which calls any path consuming syscall, and
compare it to any other solution. Then feel free to retract your claim
above.

Furthermore, you once again misrepresent what I said. Nobody is replacing
filesystem::path. afio::path_view *complements* filesystem::path with a
usefully orthogonal API design. AFIO itself switches between both path_view
and path as appropriate to use case. So will any other code. That's why the
design is so correct, path_view does not replace path, it *augments* it.

Niall


--
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/829f1a52-f28a-4aca-92fd-bb4e98e865dc%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 11, 2017 at 11:48:14 PM UTC+1, Nicol Bol=
as 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 F=
riday, August 11, 2017 at 6:29:23 PM UTC-4, Niall Douglas 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"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><br>Or we can just have a single `filesyst=
em::path` type, which you can get views of with existing types. I prefer th=
at option.</div></div></blockquote><div><br></div><div>As already covered i=
n great detail by now, if fed a string_view then one is mandated to memcpy =
the lot so it can be zero terminated before sending it to the file path con=
suming syscall.</div></div></blockquote><div><br>A problem easily solved wi=
th the types we&#39;re talking about. We don&#39;t need a replacement for `=
filesystem::path`. We <i>certainly</i> don&#39;t need some 32KB type...<br>=
</div></div></blockquote><div><br></div><div>I hate to be slightly rude, bu=
t you really don&#39;t know what you&#39;re talking about on this.</div><di=
v><br></div><div>Try doing some benchmarking of the actual cost of a potent=
ially unused 64Kb stack allocation in a routine which calls any path consum=
ing syscall, and compare it to any other solution. Then feel free to retrac=
t your claim above.</div><div><br></div><div>Furthermore, you once again mi=
srepresent what I said. Nobody is replacing filesystem::path. afio::path_vi=
ew <i>complements</i>=C2=A0filesystem::path with a usefully orthogonal API =
design. AFIO itself switches between both path_view and path as appropriate=
 to use case. So will any other code. That&#39;s why the design is so corre=
ct, path_view does not replace path, it <i>augments</i>=C2=A0it.</div><div>=
<br></div><div>Niall</div><div>=C2=A0</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/829f1a52-f28a-4aca-92fd-bb4e98e865dc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/829f1a52-f28a-4aca-92fd-bb4e98e865dc=
%40isocpp.org</a>.<br />

------=_Part_3053_1734689408.1502551424426--

------=_Part_3052_1391438201.1502551424426--

.

------=_Part_3169_1576797321.1502556868710
Content-Type: multipart/alternative;
 boundary="----=_Part_3170_1732956123.1502556868710"

------=_Part_3170_1732956123.1502556868710
Content-Type: text/plain; charset="UTF-8"

On Saturday, August 12, 2017 at 11:23:44 AM UTC-4, Niall Douglas wrote:
>
> On Friday, August 11, 2017 at 11:48:14 PM UTC+1, Nicol Bolas wrote:
>>
>> On Friday, August 11, 2017 at 6:29:23 PM UTC-4, Niall Douglas wrote:
>>>
>>>
>>>> Or we can just have a single `filesystem::path` type, which you can get
>>>> views of with existing types. I prefer that option.
>>>>
>>>
>>> As already covered in great detail by now, if fed a string_view then one
>>> is mandated to memcpy the lot so it can be zero terminated before sending
>>> it to the file path consuming syscall.
>>>
>>
>> A problem easily solved with the types we're talking about. We don't need
>> a replacement for `filesystem::path`. We *certainly* don't need some
>> 32KB type...
>>
>
> I hate to be slightly rude, but you really don't know what you're talking
> about on this.
>
> Try doing some benchmarking of the actual cost of a potentially unused
> 64Kb stack allocation in a routine which calls any path consuming syscall,
> and compare it to any other solution.
>

I'm not sure how you can benchmark "free". Because `z/cstring_view` is
exactly that. It costs nothing on the stack (OK, it costs one or two
pointers), and it costs nothing at runtime.

Your example code was:

path_view pv;
path_view::c_str zpath(pv);
open(zpath.buffer, ...);

Where `zpath` is apparently a MAX_PATH-sized object. My counter-example is:

path pv;
auto zpath = pv.zstring_view();
open(zpath.data(), ...);

You can't get cheaper than *free*, so I'd say it compares quite well with a
64Kb stack allocation.

And considering that `path_view` is useless to non-pathing APIs (string
formatting, talking to other NUL-terminating APIs, etc), while
`z/cstring_view` would be useful for them, we have two options:

1) Create a narrow solution that takes up a lot of stack space.
2) Create a broad solution that takes up virtually no stack space.

If `path_view` has a purpose beyond solving this problem, that's fine. But
we should not disregard the general utility of `z/cstring_view` just
because `path_view` is around.

To the degree that it actually will be around, of course.

--
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/78fa1116-e64f-4dcd-9bb3-6f0b71374d86%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, August 12, 2017 at 11:23:44 AM UTC-4, Niall D=
ouglas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On Friday, August 11, 2017 at 11:48:14 PM UTC+1, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, August 11, 2017=
 at 6:29:23 PM UTC-4, Niall Douglas wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><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><br>Or we can just have a single `filesystem::path` type, which =
you can get views of with existing types. I prefer that option.</div></div>=
</blockquote><div><br></div><div>As already covered in great detail by now,=
 if fed a string_view then one is mandated to memcpy the lot so it can be z=
ero terminated before sending it to the file path consuming syscall.</div><=
/div></blockquote><div><br>A problem easily solved with the types we&#39;re=
 talking about. We don&#39;t need a replacement for `filesystem::path`. We =
<i>certainly</i> don&#39;t need some 32KB type...<br></div></div></blockquo=
te><div><br></div><div>I hate to be slightly rude, but you really don&#39;t=
 know what you&#39;re talking about on this.</div><div><br></div><div>Try d=
oing some benchmarking of the actual cost of a potentially unused 64Kb stac=
k allocation in a routine which calls any path consuming syscall, and compa=
re it to any other solution.</div></div></blockquote><div><br>I&#39;m not s=
ure how you can benchmark &quot;free&quot;. Because `z/cstring_view` is exa=
ctly that. It costs nothing on the stack (OK, it costs one or two pointers)=
, and it costs nothing at runtime.<br><br>Your example code was:<br><br><di=
v style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word;"=
 class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #000;" class=3D"styled-by-prettify">path_view p=
v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>path_view</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">c_str zpath</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">pv</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>open</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">zpath</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">buffer</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">...);</span></div><=
/code></div><br>Where `zpath` is apparently a MAX_PATH-sized object. My cou=
nter-example is:<br><br><div style=3D"background-color: rgb(250, 250, 250);=
 border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">path pv</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">au=
to</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> zpath <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> pv</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">zstring_view</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>open</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">zpath</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">data</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">...);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div=
></code></div><br>You can&#39;t get cheaper than <i>free</i>, so I&#39;d sa=
y it compares quite well with a 64Kb stack allocation.<br><br>And consideri=
ng that `path_view` is useless to non-pathing APIs (string formatting, talk=
ing to other NUL-terminating APIs, etc), while `z/cstring_view` would be us=
eful for them, we have two options:<br><br>1) Create a narrow solution that=
 takes up a lot of stack space.<br>2) Create a broad solution that takes up=
 virtually no stack space.<br><br>If `path_view` has a purpose beyond solvi=
ng this problem, that&#39;s fine. But we should not disregard the general u=
tility of `z/cstring_view` just because `path_view` is around.<br><br>To th=
e degree that it actually will be around, of course.<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/78fa1116-e64f-4dcd-9bb3-6f0b71374d86%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/78fa1116-e64f-4dcd-9bb3-6f0b71374d86=
%40isocpp.org</a>.<br />

------=_Part_3170_1732956123.1502556868710--

------=_Part_3169_1576797321.1502556868710--

.

On s=C3=A1bado, 12 de agosto de 2017 09:54:28 PDT Nicol Bolas wrote:
> path pv;
> auto zpath =3D pv.zstring_view();
> open(zpath.data(), ...);
>=20
> You can't get cheaper than *free*, so I'd say it compares quite well with=
 a
> 64Kb stack allocation.

The problem is that you can't call this function with an input coming from=
=20
std::string_view. You need to modify the upper API to use std::zstring_view=
..

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/4772904.Nd9tDKj4Kx%40tjmaciei-mobl1.

.

------=_Part_3515_295257234.1502578791244
Content-Type: multipart/alternative;
 boundary="----=_Part_3516_1518582129.1502578791245"

------=_Part_3516_1518582129.1502578791245
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Saturday, August 12, 2017 at 6:15:27 PM UTC+1, Thiago Macieira wrote:
>
> On s=C3=A1bado, 12 de agosto de 2017 09:54:28 PDT Nicol Bolas wrote:=20
> > path pv;=20
> > auto zpath =3D pv.zstring_view();=20
> > open(zpath.data(), ...);=20
> >=20
> > You can't get cheaper than *free*, so I'd say it compares quite well=20
> with a=20
> > 64Kb stack allocation.=20
>
> The problem is that you can't call this function with an input coming fro=
m=20
> std::string_view. You need to modify the upper API to use=20
> std::zstring_view.=20
>

Spot on.

One very common operation which AFIO does is to split a path into leafname=
=20
and root path. This is needed to implement race free filesystem on POSIX=20
which unlike Windows doesn't let you rename or unlink via fd, so you need=
=20
to fetch the fd's current path, split it into two views, open its=20
containing directory, look up the leafname and compare st_dev and st_ino so=
=20
you know that the fd to the containing directory is the right one to use as=
=20
a base for subsequent operations.

Because the filesystem can permute randomly at any time, this operation is=
=20
in a loop, and with a potential 32Kb long path one wants to avoid copying=
=20
it frequently. Yet the root path, if working exclusively with string_view,=
=20
would always be not zero terminated, and thus you'd always have to copy it.=
=20
What we can do here is to poke a zero character in between the root path=20
and the leafname, thus afio::path_view finds a null termination and skips=
=20
the copy.

You surely will say "just use zstring_view", but then I'd need to duplicate=
=20
my public APIs with internal ones just so I can call them with a=20
zstring_view, which is silly. Much better that my internal code uses the=20
exact same public API as the end users do.

Niall

--=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/bf91faf1-3f7e-45b1-a240-6855890f48be%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, August 12, 2017 at 6:15:27 PM UTC+1, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On s=C3=A1bado, =
12 de agosto de 2017 09:54:28 PDT Nicol Bolas wrote:
<br>&gt; path pv;
<br>&gt; auto zpath =3D pv.zstring_view();
<br>&gt; open(zpath.data(), ...);
<br>&gt;=20
<br>&gt; You can&#39;t get cheaper than *free*, so I&#39;d say it compares =
quite well with a
<br>&gt; 64Kb stack allocation.
<br>
<br>The problem is that you can&#39;t call this function with an input comi=
ng from=20
<br>std::string_view. You need to modify the upper API to use std::zstring_=
view.
<br>
</blockquote><div><br></div><div>Spot on.</div><div><br></div><div>One very=
 common operation which AFIO does is to split a path into leafname and root=
 path. This is needed to implement race free filesystem on POSIX which unli=
ke Windows doesn&#39;t let you rename or unlink via fd, so you need to fetc=
h the fd&#39;s current path, split it into two views, open its containing d=
irectory, look up the leafname and compare st_dev and st_ino so you know th=
at the fd to the containing directory is the right one to use as a base for=
 subsequent operations.</div><div><br></div><div>Because the filesystem can=
 permute randomly at any time, this operation is in a loop, and with a pote=
ntial 32Kb long path one wants to avoid copying it frequently. Yet the root=
 path, if working exclusively with string_view, would always be not zero te=
rminated, and thus you&#39;d always have to copy it. What we can do here is=
 to poke a zero character in between the root path and the leafname, thus a=
fio::path_view finds a null termination and skips the copy.</div><div><br><=
/div><div>You surely will say &quot;just use zstring_view&quot;, but then I=
&#39;d need to duplicate my public APIs with internal ones just so I can ca=
ll them with a zstring_view, which is silly. Much better that my internal c=
ode uses the exact same public API as the end users do.</div><div><br></div=
><div>Niall</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/bf91faf1-3f7e-45b1-a240-6855890f48be%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bf91faf1-3f7e-45b1-a240-6855890f48be=
%40isocpp.org</a>.<br />

------=_Part_3516_1518582129.1502578791245--

------=_Part_3515_295257234.1502578791244--

.