------=_Part_795_1148130550.1418164007754
Content-Type: multipart/alternative;
 boundary="----=_Part_796_1489585555.1418164007754"

------=_Part_796_1489585555.1418164007754
Content-Type: text/plain; charset=UTF-8

string_view is not compatible with legacy C API's because its not null
terminated. The solution is to make a copy either into a std::string or a
fixed size buffer and then call the C function with that.

It would be nice to have a to_c_str() helper method which would handle the
copying and null terminating correctly. This makes adding C compatibility a
bit easier when we don't want to pay for a memory allocation with a
std::string.

char* string_view::to_c_str(array_view<char> buf) {
  auto l = std::min(length(), buf.size()-1);
  std::memcpy(buf.data(), data(), l);
  buf[l] = '\0';
  return buf.data();
}

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div>string_view is not&nbsp;compatible with legacy C API'=
s because its not null terminated. The solution is to make a copy either in=
to a std::string or a fixed size buffer and then call the C function with t=
hat.</div><div>&nbsp;</div><div>It would be nice to have a to_c_str() helpe=
r method which would handle the copying and null terminating correctly. Thi=
s makes adding C compatibility a bit easier when we don't want to pay for a=
 memory allocation with a std::string.</div><div>&nbsp;</div><div><div styl=
e=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgroun=
d-color: rgb(250, 250, 250);" class=3D"prettyprint"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><font color=3D"#000000"><span style=3D"c=
olor: rgb(0, 0, 136);" class=3D"styled-by-prettify">char</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">*</span><span st=
yle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> string_view</spa=
n><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">to_=
c_str</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pret=
tify">array_view</span><span style=3D"color: rgb(0, 136, 0);" class=3D"styl=
ed-by-prettify">&lt;char&gt;</span><span style=3D"color: rgb(0, 0, 0);" cla=
ss=3D"styled-by-prettify"> buf</span><span style=3D"color: rgb(102, 102, 0)=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: rgb(0, 0, 0);=
" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(102, 102, =
0);" class=3D"styled-by-prettify">{</span><span style=3D"color: rgb(0, 0, 0=
);" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: rg=
b(0, 0, 136);" class=3D"styled-by-prettify">auto</span><span style=3D"color=
: rgb(0, 0, 0);" class=3D"styled-by-prettify"> l </span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">min</span><span =
style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">length</span=
><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(),<=
/span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> bu=
f</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettif=
y">.</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify=
">size</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pr=
ettify">()-</span><span style=3D"color: rgb(0, 102, 102);" class=3D"styled-=
by-prettify">1</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styl=
ed-by-prettify"><br>&nbsp; std</span><span style=3D"color: rgb(102, 102, 0)=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: rgb(0, 0, 0)=
;" class=3D"styled-by-prettify">memcpy</span><span style=3D"color: rgb(102,=
 102, 0);" class=3D"styled-by-prettify">(</span><span style=3D"color: rgb(0=
, 0, 0);" class=3D"styled-by-prettify">buf</span><span style=3D"color: rgb(=
102, 102, 0);" class=3D"styled-by-prettify">.</span><span style=3D"color: r=
gb(0, 0, 0);" class=3D"styled-by-prettify">data</span><span style=3D"color:=
 rgb(102, 102, 0);" class=3D"styled-by-prettify">(),</span><span style=3D"c=
olor: rgb(0, 0, 0);" class=3D"styled-by-prettify"> data</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(),</span><span =
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> l</span><span =
style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>&nbsp; =
buf</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prett=
ify">[</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pretti=
fy">l</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pre=
ttify">]</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-=
prettify"> </span><span style=3D"color: rgb(0, 136, 0);" class=3D"styled-by=
-prettify">'\0'</span><span style=3D"color: rgb(102, 102, 0);" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styl=
ed-by-prettify"><br>&nbsp; </span><span style=3D"color: rgb(0, 0, 136);" cl=
ass=3D"styled-by-prettify">return</span><span style=3D"color: rgb(0, 0, 0);=
" class=3D"styled-by-prettify"> buf</span><span style=3D"color: rgb(102, 10=
2, 0);" class=3D"styled-by-prettify">.</span><span style=3D"color: rgb(0, 0=
, 0);" class=3D"styled-by-prettify">data</span><span style=3D"color: rgb(10=
2, 102, 0);" class=3D"styled-by-prettify">();</span><span style=3D"color: r=
gb(0, 0, 0);" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 rgb(102, 102, 0);" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></span></font></div></c=
ode></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_796_1489585555.1418164007754--
------=_Part_795_1148130550.1418164007754--

.

------=_Part_1289_780806032.1418173079245
Content-Type: multipart/alternative;
 boundary="----=_Part_1290_1881896654.1418173079245"

------=_Part_1290_1881896654.1418173079245
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 9, 2014 2:26:48 PM UTC-8, Matthew Fioravante wrote:
>
> string_view is not compatible with legacy C API's because its not null
> terminated. The solution is to make a copy either into a std::string or a
> fixed size buffer and then call the C function with that.
>

That is usually a bummer. I've filed bugs against C libraries that don't
have an explicitly-sized string interface. Naked calls to system APIs
(POSIX, Win32, etc.) are rare enough in my experience to not be worth
over-engineering solutions for them.


>
> It would be nice to have a to_c_str() helper method which would handle the
> copying and null terminating correctly. This makes adding C compatibility a
> bit easier when we don't want to pay for a memory allocation with a
> std::string.
>

My concern is that this returns an owning raw pointer. In a time when we're
trying to tell everyone to stop doing that and to use unique_ptr or whatnot
instead.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Tuesday, December 9, 2014 2:26:48 PM UTC-8, Matthew Fio=
ravante 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"=
><div>string_view is not&nbsp;compatible with legacy C API's because its no=
t null terminated. The solution is to make a copy either into a std::string=
 or a fixed size buffer and then call the C function with that.</div></div>=
</blockquote><div><br></div><div>That is usually a bummer. I've filed bugs =
against C libraries that don't have an explicitly-sized string interface. N=
aked calls to system APIs (POSIX, Win32, etc.) are rare enough in my experi=
ence to not be worth over-engineering solutions for them.</div><div>&nbsp;<=
/div><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"><div>&nb=
sp;</div><div>It would be nice to have a to_c_str() helper method which wou=
ld handle the copying and null terminating correctly. This makes adding C c=
ompatibility a bit easier when we don't want to pay for a memory allocation=
 with a std::string.</div></div></blockquote><div><br></div><div>My concern=
 is that this returns an owning raw pointer. In a time when we're trying to=
 tell everyone to stop doing that and to use unique_ptr or whatnot instead.=
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1290_1881896654.1418173079245--
------=_Part_1289_780806032.1418173079245--

.

------=_Part_1194_117089481.1418175654087
Content-Type: multipart/alternative;
 boundary="----=_Part_1195_827886515.1418175654087"

------=_Part_1195_827886515.1418175654087
Content-Type: text/plain; charset=UTF-8



On Tuesday, December 9, 2014 7:57:59 PM UTC-5, Sean Middleditch wrote:
>
> On Tuesday, December 9, 2014 2:26:48 PM UTC-8, Matthew Fioravante wrote:
>>
>> string_view is not compatible with legacy C API's because its not null
>> terminated. The solution is to make a copy either into a std::string or a
>> fixed size buffer and then call the C function with that.
>>
>
> That is usually a bummer. I've filed bugs against C libraries that don't
> have an explicitly-sized string interface. Naked calls to system APIs
> (POSIX, Win32, etc.) are rare enough in my experience to not be worth
> over-engineering solutions for them.
>
>

It depends on what C API's you're working with. POSIX is one example,
fopen() from cstdio is another. Both of which I doubt will be convinced to
adopt sized interfaces anytime soon if ever. C compatibility will at best
be an issue for a long time and at worst be an issue forever (not unlikely
at all).


>
>> It would be nice to have a to_c_str() helper method which would handle
>> the copying and null terminating correctly. This makes adding C
>> compatibility a bit easier when we don't want to pay for a memory
>> allocation with a std::string.
>>
>
> My concern is that this returns an owning raw pointer. In a time when
> we're trying to tell everyone to stop doing that and to use unique_ptr or
> whatnot instead.
>

The returned pointer is not an owning raw pointer, and actually the return
value is superfluous. It's only there because there isn't really anything
else useful to return and returning a char* means that this method could be
composed with C API functions directly.

This design is actually agnostic to the ownership of the buffer being
written to. It can be on the stack (most likely use case), heap allocated,
global, etc... All that's required is that the user construct an array_view
to represent the memory region to be written to. The array_view parameter
is also a non-owning pointer and length.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Tuesday, December 9, 2014 7:57:59 PM UTC-5, Sea=
n Middleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Tuesday, December 9, 2014 2:26:48 PM UTC-8, Matthew Fioravante =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>string_=
view is not&nbsp;compatible with legacy C API's because its not null termin=
ated. The solution is to make a copy either into a std::string or a fixed s=
ize buffer and then call the C function with that.</div></div></blockquote>=
<div><br></div><div>That is usually a bummer. I've filed bugs against C lib=
raries that don't have an explicitly-sized string interface. Naked calls to=
 system APIs (POSIX, Win32, etc.) are rare enough in my experience to not b=
e worth over-engineering solutions for them.</div><div>&nbsp;</div></div></=
blockquote><div><br></div><div>It depends on what C API's you're working wi=
th. POSIX is one example, fopen() from cstdio is another. Both of which I d=
oubt will be convinced to adopt sized interfaces anytime soon if ever. C co=
mpatibility will at best be an issue for a long time and at worst be an iss=
ue forever (not unlikely at all).</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>&nbsp;</div><div>It would be nice to have a=
 to_c_str() helper method which would handle the copying and null terminati=
ng correctly. This makes adding C compatibility a bit easier when we don't =
want to pay for a memory allocation with a std::string.</div></div></blockq=
uote><div><br></div><div>My concern is that this returns an owning raw poin=
ter. In a time when we're trying to tell everyone to stop doing that and to=
 use unique_ptr or whatnot instead.</div></div></blockquote><div><br></div>=
<div>The returned pointer is not an owning raw pointer, and actually the re=
turn value is superfluous. It's only there because there isn't really anyth=
ing else useful to return and returning a char* means that this method coul=
d be composed with C API functions directly.</div><div><br></div><div>This =
design is actually agnostic to the ownership of the buffer being written to=
.. It can be on the stack (most likely use case), heap allocated, global, et=
c... All that's required is that the user construct an array_view to repres=
ent the memory region to be written to. The array_view parameter is also a =
non-owning pointer and length.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1195_827886515.1418175654087--
------=_Part_1194_117089481.1418175654087--

.

------=_Part_4254_455605712.1418184740494
Content-Type: multipart/alternative;
 boundary="----=_Part_4255_1335460839.1418184740495"

------=_Part_4255_1335460839.1418184740495
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 10, 2014 12:40:54 PM UTC+11, Matthew Fioravante
wrote:
>
> All that's required is that the user construct an array_view to represent
> the memory region to be written to.
>

If the user has to do some work anyway, they might as well just create a
string from the string_view, e.g.:
void call_c_function(const std::string_view& sv) {
    std::string s = sv.to_string();
    c_function(s.c_str());
}

Or maybe even just:
c_function(sv.to_string().c_str());

(Assuming the C function doesn't keep the pointer after it returns)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Wednesday, December 10, 2014 12:40:54 PM UTC+11, Matthe=
w Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>All that's required is that the user construct an array_view to =
represent the memory region to be written to.<br></div></div></blockquote><=
div><br>If the user has to do some work anyway, they might as well just cre=
ate a string from the string_view, e.g.:<br><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> call_c_function</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">string_view</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> sv</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; std</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> s </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</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"style=
d-by-prettify">to_string</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; &nbsp; c_function</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">s</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c_=
str</span><span style=3D"color: #660;" class=3D"styled-by-prettify">());</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br>Or maybe even just:<br><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
 solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">c_function</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">sv</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">to_string=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">().</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">c_str</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">());</span></div></cod=
e></div><br>(Assuming the C function doesn't keep the pointer after it retu=
rns)<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4255_1335460839.1418184740495--
------=_Part_4254_455605712.1418184740494--

.

------=_Part_482_1976999707.1418225226478
Content-Type: multipart/alternative;
 boundary="----=_Part_483_1567089165.1418225226478"

------=_Part_483_1567089165.1418225226478
Content-Type: text/plain; charset=UTF-8



On Tuesday, December 9, 2014 11:12:20 PM UTC-5, sque...@gmail.com wrote:
>
> On Wednesday, December 10, 2014 12:40:54 PM UTC+11, Matthew Fioravante
> wrote:
>>
>> All that's required is that the user construct an array_view to represent
>> the memory region to be written to.
>>
>
> If the user has to do some work anyway, they might as well just create a
> string from the string_view, e.g.:
>

I'm not sure people are actually understanding what I am proposing.
Creating a std::string requires a memory allocation which may be
unacceptable for performance, particularly when the string has a known
upper bound on its length.

Here is one use case we have today where allocating memory for a
std::string is totally unnecessary and would have a large impact on
performance.

float strtol(string_view s, string_view& tail) {
  char buf[256]; //Can make this as small as whatever is the maximum string
representation for floating point + 1
  s.to_c_str(buf);
  char* e = buf;
  auto f = strtof(buf, &e);
  tail = s;
  tail.remove_prefix(e - buf);
  return f;
}

Here is another example, where you can save an allocation if your string is
"small"

//From C API
int c_function(const char* s);

//string_view wrapper
int c_function(string_view s) {
  std::string str;
  char buf[4096];
  char* p;
  if(s.length() < sizeof(buf)-1) {
    p = s.to_c_str(buf);
  } else {
    str = s;
    p = str.c_str();
  }
  return c_function(p);
}






--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Tuesday, December 9, 2014 11:12:20 PM UTC-5, sq=
ue...@gmail.com 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 Wednesday, December 10, 2014 12:40:54 PM UTC+11, Matthew Fiorav=
ante wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Al=
l that's required is that the user construct an array_view to represent the=
 memory region to be written to.<br></div></div></blockquote><div><br>If th=
e user has to do some work anyway, they might as well just create a string =
from the string_view, e.g.:<br></div></div></blockquote><div><br>I'm not su=
re people are actually understanding what I am proposing. Creating a std::s=
tring requires a memory allocation which may be unacceptable for performanc=
e, particularly when the string has a known upper bound on its length.<br><=
br>Here is one use case we have today where allocating memory for a std::st=
ring is totally unnecessary and would have a large impact on performance.<b=
r><code><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">=
float</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> strt=
ol</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">string_view s</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> string_view</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> tail</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> buf</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">256=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">];</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">//Can make this as small as=
 whatever is the maximum string representation for floating point + 1</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; s</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">to_c_str</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">buf</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">char</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> e </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b=
uf</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> f </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> strtof</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">buf</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">e<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; tail </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> s</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; tail</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">remove_prefix</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">e </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">-</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> buf</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">re=
turn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</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 style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Her=
e is another example, where you can save an allocation if your string is "s=
mall"<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">//From C API</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c_funct=
ion</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> s</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br><br></span><span style=3D"color: #800;" class=3D"styled=
-by-prettify">//string_view wrapper</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> c_function</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">string_view s</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=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"><br>&nbsp; </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> buf</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">[</span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">4096</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
har</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">s</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">length</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">buf</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">)-</span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)</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>&nbsp; &nbsp;=
 p </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> s</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">to_c_str</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">buf</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>else</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; str <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> s</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>&nbsp; &nbsp; p </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</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;" c=
lass=3D"styled-by-prettify">c_str</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> c_function</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">p<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>=
<br></code><br><br>&nbsp;<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_483_1567089165.1418225226478--
------=_Part_482_1976999707.1418225226478--

.

------=_Part_4975_1839928339.1418247802266
Content-Type: multipart/alternative;
 boundary="----=_Part_4976_2058560420.1418247802266"

------=_Part_4976_2058560420.1418247802266
Content-Type: text/plain; charset=UTF-8

On Thursday, December 11, 2014 2:27:06 AM UTC+11, Matthew Fioravante wrote:
>
> On Tuesday, December 9, 2014 11:12:20 PM UTC-5, sque...@gmail.com wrote:
>>
>> On Wednesday, December 10, 2014 12:40:54 PM UTC+11, Matthew Fioravante
>> wrote:
>>>
>>> All that's required is that the user construct an array_view to
>>> represent the memory region to be written to.
>>>
>>
>> If the user has to do some work anyway, they might as well just create a
>> string from the string_view, e.g.:
>>
>
> I'm not sure people are actually understanding what I am proposing.
> Creating a std::string requires a memory allocation which may be
> unacceptable for performance, particularly when the string has a known
> upper bound on its length.
>
> Sorry, I missed your "when we don't want to pay for a memory allocation
with a std::string" in your original post. Please ignore me.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Thursday, December 11, 2014 2:27:06 AM UTC+11, Matthew =
Fioravante 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">On Tuesday, December 9, 2014 11:12:20 PM UTC-5, <a>sque...@gmail.com</a=
> wrote:<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">On Wednesd=
ay, December 10, 2014 12:40:54 PM UTC+11, Matthew Fioravante 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"><div>All that's required i=
s that the user construct an array_view to represent the memory region to b=
e written to.<br></div></div></blockquote><div><br>If the user has to do so=
me work anyway, they might as well just create a string from the string_vie=
w, e.g.:<br></div></div></blockquote><div><br>I'm not sure people are actua=
lly understanding what I am proposing. Creating a std::string requires a me=
mory allocation which may be unacceptable for performance, particularly whe=
n the string has a known upper bound on its length.<br><br></div></div></bl=
ockquote><div>Sorry, I missed your "when we don't want to pay for a memory =
allocation with a std::string" in your original post. Please ignore me.<br>=
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4976_2058560420.1418247802266--
------=_Part_4975_1839928339.1418247802266--

.

--001a1133a818c383ae0509e56bb0
Content-Type: text/plain; charset=UTF-8

On 10 December 2014 at 09:27, Matthew Fioravante <fmatthew5876@gmail.com>
wrote:

> I'm not sure people are actually understanding what I am proposing.
> Creating a std::string requires a memory allocation which may be
> unacceptable for performance, particularly when the string has a known
> upper bound on its length.
>

That isn't sufficient.  You also have to know that you can write a '\0'
into a byte both legally (i.e., the string_view has modifiable space
underneath it) and semantically (doing so won't, say, incorrectly truncate
the string for the purposes of calling a C function on it).

This micro optimization is fragile and error-prone.

If you really need this kind of performance, why not just create your own
string_view type of class to do it, and have that class require the above
preconditions?  I don't see why it needs to be standardized, let alone
modifying string_view to support that functionality.  string_view doesn't
allow you to modify bytes in the string it refers to; that's a feature, not
a bug.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 10 December 2014 at 09:27, M=
atthew Fioravante <span dir=3D"ltr">&lt;<a href=3D"mailto:fmatthew5876@gmai=
l.com" target=3D"_blank">fmatthew5876@gmail.com</a>&gt;</span> wrote:<br><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>I&#39;m not su=
re people are actually understanding what I am proposing. Creating a std::s=
tring requires a memory allocation which may be unacceptable for performanc=
e, particularly when the string has a known upper bound on its length.<br><=
/div></blockquote></div><br>That isn&#39;t sufficient.=C2=A0 You also have =
to know that you can write a &#39;\0&#39; into a byte both legally (i.e., t=
he string_view has modifiable space underneath it) and semantically (doing =
so won&#39;t, say, incorrectly truncate the string for the purposes of call=
ing a C function on it).</div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">This micro optimization is fragile and error-prone.</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">If you rea=
lly need this kind of performance, why not just create your own string_view=
 type of class to do it, and have that class require the above precondition=
s?=C2=A0 I don&#39;t see why it needs to be standardized, let alone modifyi=
ng string_view to support that functionality. =C2=A0string_view doesn&#39;t=
 allow you to modify bytes in the string it refers to; that&#39;s a feature=
, not a bug.<br>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)=
&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" tar=
get=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1133a818c383ae0509e56bb0--

.

------=_Part_5255_1584638908.1418259518667
Content-Type: multipart/alternative;
 boundary="----=_Part_5256_2081420309.1418259518667"

------=_Part_5256_2081420309.1418259518667
Content-Type: text/plain; charset=UTF-8


On Wednesday, December 10, 2014 7:27:06 AM UTC-8, Matthew Fioravante wrote:
>
>
>
> On Tuesday, December 9, 2014 11:12:20 PM UTC-5, sque...@gmail.com wrote:
>>
>> On Wednesday, December 10, 2014 12:40:54 PM UTC+11, Matthew Fioravante
>> wrote:
>>>
>>> All that's required is that the user construct an array_view to
>>> represent the memory region to be written to.
>>>
>>
>> If the user has to do some work anyway, they might as well just create a
>> string from the string_view, e.g.:
>>
>
> I'm not sure people are actually understanding what I am proposing.
> Creating a std::string requires a memory allocation which may be
> unacceptable for performance, particularly when the string has a known
> upper bound on its length.
>

Indeed. My brain read that `memcpy` in your first post as a `strdup` and
ignored the whole purpose of the array_view. Stupid brain. Sorry.

We have an almost identical API to your proposal in our libraries, except
it's a free function and called copy_string instead of c_str (well, in our
company's convention, it's Strings::CopyInto).

I'm of the opinion that yes, this is /just/ useful enough (and small/simple
enough) to have in the library, but only just. C APIs should be fixed and
those that can't be are mostly all system APIs doing some kind of I/O or
whatnot where the allocation of a std::string is thoroughly trumped by the
cost of the syscall.

An alternative design might throw an exception (*shudder* I can't believe I
just suggested that) if the buffer is too small if one takes the "silently
truncating strings is a potential gaping security hole" mindset.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br>On Wednesday, December 10, 2014 7:27:06 AM UTC-8, Matt=
hew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Tuesday, December 9, 2014 11:12:20 PM UTC-5, <a>sque...=
@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">On Wednesday, December 10, 2014 12:40:54 PM UTC+11, Matthew Fioravante w=
rote:<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>All that=
's required is that the user construct an array_view to represent the memor=
y region to be written to.<br></div></div></blockquote><div><br>If the user=
 has to do some work anyway, they might as well just create a string from t=
he string_view, e.g.:<br></div></div></blockquote><div><br>I'm not sure peo=
ple are actually understanding what I am proposing. Creating a std::string =
requires a memory allocation which may be unacceptable for performance, par=
ticularly when the string has a known upper bound on its length.<br></div><=
/div></blockquote><div><br></div><div>Indeed. My brain read that `memcpy` i=
n your first post as a `strdup` and ignored the whole purpose of the array_=
view. Stupid brain. Sorry.</div><div><br></div><div>We have an almost ident=
ical API to your proposal in our libraries, except it's a free function and=
 called copy_string instead of c_str (well, in our company's convention, it=
's Strings::CopyInto).</div><div><br></div><div>I'm of the opinion that yes=
, this is /just/ useful enough (and small/simple enough) to have in the lib=
rary, but only just. C APIs should be fixed and those that can't be are mos=
tly all system APIs doing some kind of I/O or whatnot where the allocation =
of a std::string is thoroughly trumped by the cost of the syscall.</div><di=
v><br></div><div>An alternative design might throw an exception (*shudder* =
I can't believe I just suggested that) if the buffer is too small if one ta=
kes the "silently truncating strings is a potential gaping security hole" m=
indset.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5256_2081420309.1418259518667--
------=_Part_5255_1584638908.1418259518667--

.

------=_Part_996_44514102.1418259859013
Content-Type: multipart/alternative;
 boundary="----=_Part_997_824203158.1418259859013"

------=_Part_997_824203158.1418259859013
Content-Type: text/plain; charset=UTF-8



On Wednesday, December 10, 2014 6:57:28 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On 10 December 2014 at 09:27, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
>
>> I'm not sure people are actually understanding what I am proposing.
>> Creating a std::string requires a memory allocation which may be
>> unacceptable for performance, particularly when the string has a known
>> upper bound on its length.
>>
>
> That isn't sufficient.  You also have to know that you can write a '\0'
> into a byte both legally (i.e., the string_view has modifiable space
> underneath it)
>

We aren't writing to the bytes pointed to by the string_view. We're copying
the data from the string_view to another buffer, null terminating it, and
passing it to the c function. We cannot write to the data pointed to by the
view because first the view is const and second we cannot write a 0 to the
byte after the view. Take a look at the examples again.


> and semantically (doing so won't, say, incorrectly truncate the string for
> the purposes of calling a C function on it).
>

If you want to avoid a heap allocation you are forced to accept truncation.
In some cases truncation is ok because you have an upper bound on the
possible inputs the function accepts (strtof()). The second example shows
how to get a fast copy on the stack for small enough strings and falling
back to heap allocation for larger ones.


> This micro optimization is fragile and error-prone.
>

Perhaps, but its more error prone to have to write the copy and null
terminate logic yourself everytime. Granted, this use case is small enough
that its probably ok to just tell people to deal with it themselves.

>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Wednesday, December 10, 2014 6:57:28 PM UTC-5, =
Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>On 10 December 2014 at 09:27, Matthew Fioravante <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"-yzumqClb44J" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">fmatth...@gmail.com</a>&g=
t;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div>I'm not sure people are actually understanding what I am proposing.=
 Creating a std::string requires a memory allocation which may be unaccepta=
ble for performance, particularly when the string has a known upper bound o=
n its length.<br></div></blockquote></div><br>That isn't sufficient.&nbsp; =
You also have to know that you can write a '\0' into a byte both legally (i=
..e., the string_view has modifiable space underneath it) </div></div></bloc=
kquote><div><br></div><div><span style=3D"font-size: 13.1428575515747px;">W=
e aren't writing to the bytes pointed to by the string_view. We're copying =
the data from the string_view to another buffer, null terminating it, and p=
assing it to the c function. We cannot write to the data pointed to by the =
view because first the view is const and second we cannot write a 0 to the =
byte after the view. Take a look at the examples again.</span><br></div><di=
v>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>and semantically (doing so won't, say, incorrectly truncate the strin=
g for the purposes of calling a C function on it).</div></div></blockquote>=
<div><br></div><div>If you want to avoid a heap allocation you are forced t=
o accept truncation. In some cases truncation is ok because you have an upp=
er bound on the possible inputs the function accepts (strtof()). The second=
 example shows how to get a fast copy on the stack for small enough strings=
 and falling back to heap allocation for larger ones.</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div=
><div>This micro optimization is fragile and error-prone.</div></div></bloc=
kquote><div><br></div><div>Perhaps, but its more error prone to have to wri=
te the copy and null terminate logic yourself everytime. Granted, this use =
case is small enough that its probably ok to just tell people to deal with =
it themselves.</div><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>
</div></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_997_824203158.1418259859013--
------=_Part_996_44514102.1418259859013--

.

--001a113b5a64ef91c00509e7ac60
Content-Type: text/plain; charset=UTF-8

On 10 December 2014 at 19:04, Matthew Fioravante <fmatthew5876@gmail.com>
wrote:

> We aren't writing to the bytes pointed to by the string_view. We're
> copying the data from the string_view to another buffer, null terminating
> it, and passing it to the c function. We cannot write to the data pointed
> to by the view because first the view is const and second we cannot write a
> 0 to the byte after the view. Take a look at the examples again.
>

Your implementation has something writing into the data referred to in an
array_view, which isn't allowed last I checked.  Allowing modification of
contents through an array_view is a bad idea for exactly the same reasons
it is a bad idea to allow it in string_view.

The next problem with it is the std::min call, which makes it very
difficult to reason about whether or not the resulting string is
truncated.  This alone makes it almost as bad to reason about as using
strncpy.

It also doesn't handle zero-length destination buffers, which is
problematic if you want to fill up runtime sized buffers.

Generally, we prefer to return things and take advantage of RVO rather than
pass them in and replace their contents.  This could be accomplished with,
say, a templated size and return a std::array of that size (or throw if it
isn't large enough), but I just don't find this kind of micro optimization
necessary often enough to be worthwhile as a standard feature.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 10 December 2014 at 19:04, Matthew Fioravante <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div><span style=3D"font-size=
:13.1428575515747px">We aren&#39;t writing to the bytes pointed to by the s=
tring_view. We&#39;re copying the data from the string_view to another buff=
er, null terminating it, and passing it to the c function. We cannot write =
to the data pointed to by the view because first the view is const and seco=
nd we cannot write a 0 to the byte after the view. Take a look at the examp=
les again.</span></div></blockquote><div><br></div><div>Your implementation=
 has something writing into the data referred to in an array_view, which is=
n&#39;t allowed last I checked.=C2=A0 Allowing modification of contents thr=
ough an array_view is a bad idea for exactly the same reasons it is a bad i=
dea to allow it in string_view.</div><div><br></div><div>The next problem w=
ith it is the std::min call, which makes it very difficult to reason about =
whether or not the resulting string is truncated.=C2=A0 This alone makes it=
 almost as bad to reason about as using strncpy.</div><div><br></div><div>I=
t also doesn&#39;t handle zero-length destination buffers, which is problem=
atic if you want to fill up runtime sized buffers.</div><div><br></div><div=
>Generally, we prefer to return things and take advantage of RVO rather tha=
n pass them in and replace their contents.=C2=A0 This could be accomplished=
 with, say, a templated size and return a std::array of that size (or throw=
 if it isn&#39;t large enough), but I just don&#39;t find this kind of micr=
o optimization necessary often enough to be worthwhile as a standard featur=
e.</div></div></div><div class=3D"gmail_extra">-- <br><div class=3D"gmail_s=
ignature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt=
;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113b5a64ef91c00509e7ac60--

.

------=_Part_4100_228359386.1418267478222
Content-Type: multipart/alternative;
 boundary="----=_Part_4101_482923313.1418267478222"

------=_Part_4101_482923313.1418267478222
Content-Type: text/plain; charset=UTF-8



On Wednesday, December 10, 2014 9:38:48 PM UTC-5, Nevin ":-)" Liber wrote:
>
>
> On 10 December 2014 at 19:04, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
>
>> We aren't writing to the bytes pointed to by the string_view. We're
>> copying the data from the string_view to another buffer, null terminating
>> it, and passing it to the c function. We cannot write to the data pointed
>> to by the view because first the view is const and second we cannot write a
>> 0 to the byte after the view. Take a look at the examples again.
>>
>
> Your implementation has something writing into the data referred to in an
> array_view, which isn't allowed last I checked.
>

array_view is not a const view like string_view and should not be. While
you can have an array_view<const T> (or carray_view<T>), you don't always
need or want it. An array_view essentially just encapsulates a pair of
pointers, or if you like a pointer and a size. Instead of passing around 2
objects you pass around one. The use case I have here is a common idiom,
you use the array_view to specify a window of memory with which to write
to. This is much safer, easier to read / maintain then juggling 2 pointers
or a pointer and a length. It's also more efficient than passing a
std::vector by reference.

I get the feeling people really haven't tried playing with array_view very
much in their own code to understand just how amazingly awesome it is. If
you mostly code with contiguous data structures (i.e. prefer std::vector
over almost everything else) then array_view is useful all over the place.


>   Allowing modification of contents through an array_view is a bad idea
> for exactly the same reasons it is a bad idea to allow it in string_view.
>



>
> The next problem with it is the std::min call, which makes it very
> difficult to reason about whether or not the resulting string is
> truncated.  This alone makes it almost as bad to reason about as using
> strncpy.
>

Truncation is part of contract of the function. If you don't want
truncation check the length first or use std::string.


>
> It also doesn't handle zero-length destination buffers, which is
> problematic if you want to fill up runtime sized buffers.
>

I suppose this is a bug, although I'd be tempted to change the definition
of the method to be "undefined behavior" if a zero length buffer is used
because a zero length buffer can never represent a null terminated string.

>
> Generally, we prefer to return things and take advantage of RVO rather
> than pass them in and replace their contents.  This could be accomplished
> with, say, a templated size and return a std::array of that size (or throw
> if it isn't large enough),
>

We aren't creating a new object here, instead we're filling up a
pre-existing one. Using an array_view in/out parameter provides a lot more
flexibility because you can write to any block of memory you like, whether
its a whole array or a window into a subset of the array.



> but I just don't find this kind of micro optimization necessary often
> enough to be worthwhile as a standard feature.
>

Fair enough


>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Wednesday, December 10, 2014 9:38:48 PM UTC-5, =
Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><br><div class=3D"gmail_quote">On 10 December 2014 at 19:04=
, Matthew Fioravante <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"63i0u8AtOc4J" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">fmatth...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><=
span style=3D"font-size:13.1428575515747px">We aren't writing to the bytes =
pointed to by the string_view. We're copying the data from the string_view =
to another buffer, null terminating it, and passing it to the c function. W=
e cannot write to the data pointed to by the view because first the view is=
 const and second we cannot write a 0 to the byte after the view. Take a lo=
ok at the examples again.</span></div></blockquote><div><br></div><div>Your=
 implementation has something writing into the data referred to in an array=
_view, which isn't allowed last I checked.</div></div></div></div></blockqu=
ote><div><br></div><div>array_view is not a const view like string_view and=
 should not be. While you can have an array_view&lt;const T&gt; (or carray_=
view&lt;T&gt;), you don't always need or want it. An array_view essentially=
 just encapsulates a pair of pointers, or if you like a pointer and a size.=
 Instead of passing around 2 objects you pass around one. The use case I ha=
ve here is a common idiom, you use the array_view to specify a window of me=
mory with which to write to. This is much safer, easier to read / maintain =
then juggling 2 pointers or a pointer and a length. It's also more efficien=
t than passing a std::vector by reference.</div><div><br></div><div>I get t=
he feeling people really haven't tried playing with array_view very much in=
 their own code to understand just how amazingly awesome it is. If you most=
ly code with contiguous data structures (i.e. prefer std::vector over almos=
t everything else) then array_view is useful all over the place.</div><div>=
&nbsp;</div><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"><=
div><div class=3D"gmail_quote"><div>&nbsp; Allowing modification of content=
s through an array_view is a bad idea for exactly the same reasons it is a =
bad idea to allow it in string_view.</div></div></div></div></blockquote><d=
iv><br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>The ne=
xt problem with it is the std::min call, which makes it very difficult to r=
eason about whether or not the resulting string is truncated.&nbsp; This al=
one makes it almost as bad to reason about as using strncpy.</div></div></d=
iv></div></blockquote><div><br></div><div>Truncation is part of contract of=
 the function. If you don't want truncation check the length first or use s=
td::string.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>=
It also doesn't handle zero-length destination buffers, which is problemati=
c if you want to fill up runtime sized buffers.</div></div></div></div></bl=
ockquote><div><br></div><div>I suppose this is a bug, although I'd be tempt=
ed to change the definition of the method to be "undefined behavior" if a z=
ero length buffer is used because a zero length buffer can never represent =
a null terminated string.&nbsp;</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div=
>Generally, we prefer to return things and take advantage of RVO rather tha=
n pass them in and replace their contents.&nbsp; This could be accomplished=
 with, say, a templated size and return a std::array of that size (or throw=
 if it isn't large enough), </div></div></div></div></blockquote><div><br><=
/div><div><div style=3D"font-size: 13.1428575515747px;">We aren't creating =
a new object here, instead we're filling up a pre-existing one. Using an ar=
ray_view in/out parameter provides a lot more flexibility because you can w=
rite to any block of memory you like, whether its a whole array or a window=
 into a subset of the array.</div></div><div><br></div><div>&nbsp;</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div>but I just don't find this kind of micro optimization=
 necessary often enough to be worthwhile as a standard feature.</div></div>=
</div></div></blockquote><div><br></div><div>Fair enough</div><div><span st=
yle=3D"font-size: 13px;">&nbsp;</span></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>
</div></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4101_482923313.1418267478222--
------=_Part_4100_228359386.1418267478222--

.

------=_Part_486_2065119898.1418392672276
Content-Type: multipart/alternative;
 boundary="----=_Part_487_839422872.1418392672276"

------=_Part_487_839422872.1418392672276
Content-Type: text/plain; charset=UTF-8

On Thursday, December 11, 2014 4:11:18 AM UTC+1, Matthew Fioravante wrote:
>
>
>
> On Wednesday, December 10, 2014 9:38:48 PM UTC-5, Nevin ":-)" Liber wrote:
>>
>>
>> On 10 December 2014 at 19:04, Matthew Fioravante <fmatth...@gmail.com>
>> wrote:
>>
>>> We aren't writing to the bytes pointed to by the string_view. We're
>>> copying the data from the string_view to another buffer, null terminating
>>> it, and passing it to the c function. We cannot write to the data pointed
>>> to by the view because first the view is const and second we cannot write a
>>> 0 to the byte after the view. Take a look at the examples again.
>>>
>>
>> Your implementation has something writing into the data referred to in an
>> array_view, which isn't allowed last I checked.
>>
>
> array_view is not a const view like string_view and should not be.
>

Wasn't string_view recently made non-const?

Truncation is part of contract of the function. If you don't want
> truncation check the length first or use std::string.
>

Is actual truncation ever not a bug?
IMO you should abort / throw instead of truncate.

>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Thursday, December 11, 2014 4:11:18 AM UTC+1, Matthew F=
ioravante 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"lt=
r"><br><br>On Wednesday, December 10, 2014 9:38:48 PM UTC-5, Nevin ":-)" Li=
ber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br=
><div class=3D"gmail_quote">On 10 December 2014 at 19:04, Matthew Fioravant=
e <span dir=3D"ltr">&lt;<a>fmatth...@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex"><div><span style=3D"font-size:13.1428575515747px">We aren't w=
riting to the bytes pointed to by the string_view. We're copying the data f=
rom the string_view to another buffer, null terminating it, and passing it =
to the c function. We cannot write to the data pointed to by the view becau=
se first the view is const and second we cannot write a 0 to the byte after=
 the view. Take a look at the examples again.</span></div></blockquote><div=
><br></div><div>Your implementation has something writing into the data ref=
erred to in an array_view, which isn't allowed last I checked.</div></div><=
/div></div></blockquote><div><br></div><div>array_view is not a const view =
like string_view and should not be. </div></div></blockquote><div><br></div=
><div>Wasn't string_view recently made non-const?</div><div><br></div><bloc=
kquote 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>Truncation is=
 part of contract of the function. If you don't want truncation check the l=
ength first or use std::string.</div></div></blockquote><div><br></div><div=
>Is actual truncation ever not a bug?</div><div>IMO you should abort / thro=
w instead of truncate.</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><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"><di=
v>
</div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_487_839422872.1418392672276--
------=_Part_486_2065119898.1418392672276--

.

------=_Part_514_1630216904.1418392774606
Content-Type: multipart/alternative;
 boundary="----=_Part_515_1459137102.1418392774606"

------=_Part_515_1459137102.1418392774606
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 10, 2014 4:27:06 PM UTC+1, Matthew Fioravante wrote:
>
> Here is one use case we have today where allocating memory for a
> std::string is totally unnecessary and would have a large impact on
> performance.
>

Right, though I'm expecting variants of these functions taking string_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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Wednesday, December 10, 2014 4:27:06 PM UTC+1, Matthew =
Fioravante 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"><div>Here is one use case we have today where allocating memory for a s=
td::string is totally unnecessary and would have a large impact on performa=
nce.<br></div></div></blockquote><div><br></div><div>Right, though I'm expe=
cting variants of these functions taking string_view.&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_515_1459137102.1418392774606--
------=_Part_514_1630216904.1418392774606--

.

On 12 December 2014 at 15:57, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Wasn't string_view recently made non-const?

I wonder what makes people think that's the case. In N4335 it
certainly isn't mutable.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c2482e22de43050a0564b4
Content-Type: text/plain; charset=UTF-8

On Fri, Dec 12, 2014 at 3:02 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> On 12 December 2014 at 15:57, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
> > Wasn't string_view recently made non-const?
>
> I wonder what makes people think that's the case. In N4335 it
> certainly isn't mutable.
>
>
http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-32-Sneak-Preview-of-C17#time=12m04s

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Dec 12, 2014 at 3:02 PM, Ville Voutilainen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vo=
utilainen@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex">On 12 December 20=
14 at 15:57, Olaf van der Spek &lt;<a href=3D"mailto:olafvdspek@gmail.com">=
olafvdspek@gmail.com</a>&gt; wrote:<br>
&gt; Wasn&#39;t string_view recently made non-const?<br>
<br>
I wonder what makes people think that&#39;s the case. In N4335 it<br>
certainly isn&#39;t mutable.<br><br></blockquote><div><a href=3D"http://cha=
nnel9.msdn.com/Shows/C9-GoingNative/GoingNative-32-Sneak-Preview-of-C17#tim=
e=3D12m04s">http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-32-Sn=
eak-Preview-of-C17#time=3D12m04s</a>=C2=A0</div></div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2482e22de43050a0564b4--

.

On 12 December 2014 at 16:05, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> > Wasn't string_view recently made non-const?
>> I wonder what makes people think that's the case. In N4335 it
>> certainly isn't mutable.
> http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-32-Sneak-Preview-of-C17#time=12m04s


Yes, I suggest you read the comments.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bf0e1f27fbba0050a0577c1
Content-Type: text/plain; charset=UTF-8

Ah, your comment wasn't there when I first viewed this.

I was about to make a comment about it myself but either didn't or it
didn't pass moderation.

On Fri, Dec 12, 2014 at 3:08 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> On 12 December 2014 at 16:05, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
> >> > Wasn't string_view recently made non-const?
> >> I wonder what makes people think that's the case. In N4335 it
> >> certainly isn't mutable.
> >
> http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-32-Sneak-Preview-of-C17#time=12m04s
>
>
> Yes, I suggest you read the comments.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/LEPhIf_msXw/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>


--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Ah, your comment wasn&#39;t there when I first viewed this=
..<div><br></div><div>I was about to make a comment about it myself but eith=
er didn&#39;t or it didn&#39;t pass moderation.</div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Fri, Dec 12, 2014 at 3:08 PM, =
Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen=
@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><span class=3D"">On 12 December 2014 at =
16:05, Olaf van der Spek &lt;<a href=3D"mailto:olafvdspek@gmail.com">olafvd=
spek@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; Wasn&#39;t string_view recently made non-const?<br>
&gt;&gt; I wonder what makes people think that&#39;s the case. In N4335 it<=
br>
&gt;&gt; certainly isn&#39;t mutable.<br>
&gt; <a href=3D"http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-3=
2-Sneak-Preview-of-C17#time=3D12m04s" target=3D"_blank">http://channel9.msd=
n.com/Shows/C9-GoingNative/GoingNative-32-Sneak-Preview-of-C17#time=3D12m04=
s</a><br>
<br>
<br>
</span>Yes, I suggest you read the comments.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/LEPhIf_msXw/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/LEPhIf_msXw=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br clear=3D"all"><div><br></div>-- <br><div=
 class=3D"gmail_signature">Olaf</div>
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bf0e1f27fbba0050a0577c1--

.