------=_Part_171_317021.1380367139059
Content-Type: text/plain; charset=ISO-8859-1

I do not understand the intent of string_view and in what way it would be
usefull for me.
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html>

I understand that I get read access to a string without making an extra
copy and the only mutable operation I can perform is to remove n chars at
the front or the back.

But the "non-owning" part gives me shivers. It implies that the instance of
the view I get should not outlive the original object. If the intent of
this type is to move references around, tracking the owner might get tricky.

Then I have no guarantee whatsoever that the string I am viewing will not
change. For any operation other than subsitution, the view might be
invalidated.

And, finally, a lot of potentially usefull methods are not available, such
as trim (left, right, with a list of chars) or substring (before, after).

Can someone point out use cases for this type?
Thanks,
Vincent

--

---
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_171_317021.1380367139059
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I do not understand the intent of string_view and in what =
way it would be usefull for me.<br>&lt;http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2013/n3762.html&gt; <br><br>I understand that I get read acc=
ess to a string without making an extra copy and the only mutable operation=
 I can perform is to remove n chars at the front or the back. <br><br>But t=
he "non-owning" part gives me shivers. It implies that the instance of the =
view I get should not outlive the original object. If the intent of this ty=
pe is to move references around, tracking the owner might get tricky.<br><b=
r>Then I have no guarantee whatsoever that the string I am viewing will not=
 change. For any operation other than subsitution, the view might be invali=
dated.<br><br>And, finally, a lot of potentially usefull methods are not av=
ailable, such as trim (left, right, with a list of chars) or substring (bef=
ore, after).<br><br>Can someone point out use cases for this type?<br>Thank=
s,<br>Vincent<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_171_317021.1380367139059--

.

--001a11c3dfba52695504e7701351
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Sep 28, 2013 at 1:18 PM, Vincent Jacquet <vjacquet@flowgroup.fr>wrote:

> But the "non-owning" part gives me shivers. It implies that the instance
> of the view I get should not outlive the original object. If the intent of
> this type is to move references around, tracking the owner might get tricky.
>
> Then I have no guarantee whatsoever that the string I am viewing will not
> change. For any operation other than subsitution, the view might be
> invalidated.
>
>

Indeed, if you want to keep these garantees, you already have std::string
available.
string_view could be seen as both an optimization and a contract (like
references) that imply that the viewed data is indeed accessible in a valid
way.

Don't forget that it's inspired by real use. For example, it is common to
optimize applications with a lot of text loaded at runtime by having a big
pool of all texts and manipulating
only string views of these texts in the application, so that no copy is
done. Obviously, to transform text you still need copying it and modifying
it which std::string already provide.

Think about it as an optimization tool, or as a contract saying that what's
passed to a function have to be alive at least the time of the function
call.


> And, finally, a lot of potentially usefull methods are not available, such
> as trim (left, right, with a list of chars) or substring (before, after).
>
>


> Can someone point out use cases for this type?
>

In the document there are references to usage in Google (Chrome), LLVM and
Microsoft (and I believe Facebook too) code bases, some of them you can
look at freely.

--

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

--001a11c3dfba52695504e7701351
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Sep 28, 2013 at 1:18 PM, Vincent Jacquet <span dir=3D"ltr">=
&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flo=
wgroup.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">But the &quot;non-owning&qu=
ot; part gives me shivers. It implies that the instance of the view I get s=
hould not outlive the original object. If the intent of this type is to mov=
e references around, tracking the owner might get tricky.<br>
<br>Then I have no guarantee whatsoever that the string I am viewing will n=
ot change. For any operation other than subsitution, the view might be inva=
lidated.<br><br></div></blockquote><div><br></div><div><br></div><div>Indee=
d, if you want to keep these garantees, you already have std::string availa=
ble.</div>
<div>string_view could be seen as both an optimization and a contract (like=
 references) that imply that the viewed data is indeed accessible in a vali=
d way.</div><div><br></div><div>Don&#39;t forget that it&#39;s inspired by =
real use. For example, it is common to optimize applications with a lot of =
text loaded at runtime by having a big pool of all texts and manipulating<b=
r>
only string views of these texts in the application, so that no copy is don=
e. Obviously, to transform text you still need copying it and modifying it =
which std::string already provide.</div><div><br></div><div>Think about it =
as an optimization tool, or as a contract saying that what&#39;s passed to =
a function have to be alive at least the time of the function call.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">And, finally,=
 a lot of potentially usefull methods are not available, such as trim (left=
, right, with a list of chars) or substring (before, after).<br>
<br></div></blockquote><div><br></div><div>=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">Can someone point out use cases for this type?<br>=
</div>
</blockquote><div><br></div><div>In the document there are references to us=
age in Google (Chrome), LLVM and Microsoft (and I believe Facebook too) cod=
e bases, some of them you can look at freely.</div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c3dfba52695504e7701351--

.

--089e0160b5e4e72d8204e7701572
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 28, 2013 at 1:40 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
wrote:

> Think about it as an optimization tool, or as a contract saying that
> what's passed to a function have to be alive at least the time of the
> function call.


To clarify, the point is to totally avoid copy when you know by design that
it's not necessary.

--=20

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

--089e0160b5e4e72d8204e7701572
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sat, Sep 28, 2013 at 1:40 PM, Klaim - Jo=EBl Lamotte <span dir=3D"ltr">&=
lt;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Think about it as an optimization tool, or a=
s a contract saying that what&#39;s passed to a function have to be alive a=
t least the time of the function call.</blockquote>
</div><br>To clarify, the point is to totally avoid copy when you know by d=
esign that it&#39;s not necessary.</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0160b5e4e72d8204e7701572--

.

On 09/28/2013 01:18 PM, Vincent Jacquet wrote:

> Can someone point out use cases for this type?

In one word: parsing.

Most optimized parsers/lexers I am familiar with uses something
reminiscent of string_view.

For example, if you need to parse an XML document then you need to
match start and end tags. With string_view you do not have to allocate
a string containing the end tag just to compare it to the start tag.

String_view is also useful if you need to skip over parts of the
document without doing memory allocation.

--

---
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_790_5366394.1380371019637
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks but, basically, I find the "others did it, so we should do it"=20
argument kind of weak. I mean as it is inspired by real use, can we have=20
some of them as example and some figures? i.e. under these conditions, the=
=20
use of "string_view" in place of "string" resulted in a performance=20
improvement of x%, and a decrease of memory consumption of y%.
In the document n3762,  I found links to definition of similar classes at=
=20
google or llvm, not to use cases. I have not found any reference to=20
Microsoft or facebook. Maybe am I not looking a the complete document?


On Saturday, September 28, 2013 1:40:53 PM UTC+2, Klaim - Jo=EBl Lamotte=20
wrote:
>
>
>
>
> On Sat, Sep 28, 2013 at 1:18 PM, Vincent Jacquet <vjac...@flowgroup.fr<ja=
vascript:>
> > wrote:
>
>> But the "non-owning" part gives me shivers. It implies that the instance=
=20
>> of the view I get should not outlive the original object. If the intent =
of=20
>> this type is to move references around, tracking the owner might get tri=
cky.
>>
>> Then I have no guarantee whatsoever that the string I am viewing will no=
t=20
>> change. For any operation other than subsitution, the view might be=20
>> invalidated.
>>
>>
>
> Indeed, if you want to keep these garantees, you already have std::string=
=20
> available.
> string_view could be seen as both an optimization and a contract (like=20
> references) that imply that the viewed data is indeed accessible in a val=
id=20
> way.
>
> Don't forget that it's inspired by real use. For example, it is common to=
=20
> optimize applications with a lot of text loaded at runtime by having a bi=
g=20
> pool of all texts and manipulating
> only string views of these texts in the application, so that no copy is=
=20
> done. Obviously, to transform text you still need copying it and modifyin=
g=20
> it which std::string already provide.
>
> Think about it as an optimization tool, or as a contract saying that=20
> what's passed to a function have to be alive at least the time of the=20
> function call.
> =20
>
>> And, finally, a lot of potentially usefull methods are not available,=20
>> such as trim (left, right, with a list of chars) or substring (before,=
=20
>> after).
>>
>>
> =20
>
>> Can someone point out use cases for this type?
>>
>
> In the document there are references to usage in Google (Chrome), LLVM an=
d=20
> Microsoft (and I believe Facebook too) code bases, some of them you can=
=20
> look at freely.
>

--=20

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

------=_Part_790_5366394.1380371019637
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks but, basically, I find the "others did it, so we sh=
ould do it" argument kind of weak. I mean as it is inspired by real use, ca=
n we have some of them as example and some figures? i.e. under these condit=
ions, the use of "string_view" in place of "string" resulted in a performan=
ce improvement of x%, and a decrease of memory consumption of y%.<br>In the=
 document n3762,&nbsp; I found links to definition of similar classes at go=
ogle or llvm, not to use cases. I have not found any reference to Microsoft=
 or facebook. Maybe am I not looking a the complete document?<br><br><br>On=
 Saturday, September 28, 2013 1:40:53 PM UTC+2, Klaim - Jo=EBl Lamotte wrot=
e:<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"><br><div><b=
r><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 1:18 PM, Vincent J=
acquet <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"0IO5r1INi5gJ">vjac...@flowgroup.fr</a>&gt;</span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">But the "non-owning" part g=
ives me shivers. It implies that the instance of the view I get should not =
outlive the original object. If the intent of this type is to move referenc=
es around, tracking the owner might get tricky.<br>
<br>Then I have no guarantee whatsoever that the string I am viewing will n=
ot change. For any operation other than subsitution, the view might be inva=
lidated.<br><br></div></blockquote><div><br></div><div><br></div><div>Indee=
d, if you want to keep these garantees, you already have std::string availa=
ble.</div>
<div>string_view could be seen as both an optimization and a contract (like=
 references) that imply that the viewed data is indeed accessible in a vali=
d way.</div><div><br></div><div>Don't forget that it's inspired by real use=
.. For example, it is common to optimize applications with a lot of text loa=
ded at runtime by having a big pool of all texts and manipulating<br>
only string views of these texts in the application, so that no copy is don=
e. Obviously, to transform text you still need copying it and modifying it =
which std::string already provide.</div><div><br></div><div>Think about it =
as an optimization tool, or as a contract saying that what's passed to a fu=
nction have to be alive at least the time of the function call.</div>
<div>&nbsp;</div><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">And, final=
ly, a lot of potentially usefull methods are not available, such as trim (l=
eft, right, with a list of chars) or substring (before, after).<br>
<br></div></blockquote><div><br></div><div>&nbsp;</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">Can someone point out use cases for this type?<=
br></div>
</blockquote><div><br></div><div>In the document there are references to us=
age in Google (Chrome), LLVM and Microsoft (and I believe Facebook too) cod=
e bases, some of them you can look at freely.</div></div></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_790_5366394.1380371019637--

.

------=_Part_16_26077872.1380373240757
Content-Type: text/plain; charset=ISO-8859-1

I understand the handling part of a string as if it was a string, but
"without doing memory allocation part". What I do not get is the
"non-owning" part. I cannot reason locally because of this. Whenever I will
use a string_view, I will have to think about the owner. For instance, I
cannot store a string_view in a class or a container unless I am sure that
the owner will be around longer than the instance this class or the
container.

If instead I define a type as "mutable range on an immutable shared string"
(I call that a "stick", all puns intended and assumed), I can still provide
trimming, truncating and slicing without memory allocation but I can also
guarante that the underlying string will not change ever (of course, under
construction, my class will have to either take ownership of the string or
create a unique copy). As a user of the class, I do not have to worry about
the lifetime of the initial string. I can pass it around, even to other
threads... I just find this safer.

Thanks,
Vincent

On Saturday, September 28, 2013 2:09:08 PM UTC+2, Bjorn Reese wrote:
>
> On 09/28/2013 01:18 PM, Vincent Jacquet wrote:
>
> > Can someone point out use cases for this type?
>
> In one word: parsing.
>
> Most optimized parsers/lexers I am familiar with uses something
> reminiscent of string_view.
>
> For example, if you need to parse an XML document then you need to
> match start and end tags. With string_view you do not have to allocate
> a string containing the end tag just to compare it to the start tag.
>
> String_view is also useful if you need to skip over parts of the
> document without doing memory allocation.
>
>

--

---
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_16_26077872.1380373240757
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I understand the handling part of a string as if it was a =
string, but "without doing memory allocation part". What I do not get is th=
e "non-owning" part. I cannot reason locally because of this. Whenever I wi=
ll use a string_view, I will have to think about the owner. For instance, I=
 cannot store a string_view in a class or a container unless I am sure that=
 the owner will be around longer than the instance this class or the contai=
ner.<br><br>If instead I define a type as "mutable range on an immutable sh=
ared string" (I call that a "stick", all puns intended and assumed), I can =
still provide trimming, truncating and slicing without memory allocation bu=
t I can also&nbsp; guarante that the underlying string will not change ever=
 (of course, under construction, my class will have to either take ownershi=
p of the string or create a unique copy). As a user of the class, I do not =
have to worry about the lifetime of the initial string. I can pass it aroun=
d, even to other threads... I just find this safer.<br><br>Thanks,<br>Vince=
nt<br><br>On Saturday, September 28, 2013 2:09:08 PM UTC+2, Bjorn Reese wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On 09/28/2013 01:18 PM, Vin=
cent Jacquet wrote:
<br>
<br>&gt; Can someone point out use cases for this type?
<br>
<br>In one word: parsing.
<br>
<br>Most optimized parsers/lexers I am familiar with uses something
<br>reminiscent of string_view.
<br>
<br>For example, if you need to parse an XML document then you need to
<br>match start and end tags. With string_view you do not have to allocate
<br>a string containing the end tag just to compare it to the start tag.
<br>
<br>String_view is also useful if you need to skip over parts of the
<br>document without doing memory allocation.
<br>
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_16_26077872.1380373240757--

.

--089e0160b5e447943204e7715aa5
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Sep 28, 2013 at 2:23 PM, Vincent Jacquet <vjacquet@flowgroup.fr>wrote:

> Thanks but, basically, I find the "others did it, so we should do it"
> argument kind of weak.
>

It's not an argument, I'm saying there was a need before there was a
proposal.
The need is well known for developers having to work with text, like
parsers as Vincent pointed.
The argument is to work with strings without having to copying them when
it's not necessary, for example when only needing reading them.


> I mean as it is inspired by real use, can we have some of them as example
> and some figures? i.e. under these conditions, the use of "string_view" in
> place of "string" resulted in a performance improvement of x%, and a
> decrease of memory consumption of y%.
>

I don't know any such benchmark but I don't see how adding copies would
make algorithms not needing copies to be faster. I'm not sure if it's
necessary,
but I guess you can request some comparison to the author.

Also, the other argument for string_view (previously string_ref) is that it
can work with an array too, which is better than passing
You'll find a long discussion on string_view in the archives of this forum.

--

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

--089e0160b5e447943204e7715aa5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Sep 28, 2013 at 2:23 PM, Vincent Jacquet <span dir=3D"ltr">=
&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flo=
wgroup.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Thanks but, basically, I fi=
nd the &quot;others did it, so we should do it&quot; argument kind of weak.=
</div>
</blockquote><div><br></div><div>It&#39;s not an argument, I&#39;m saying t=
here was a need before there was a proposal.</div><div>The need is well kno=
wn for developers having to work with text, like parsers as Vincent pointed=
..</div>
<div>The argument is to work with strings without having to copying them wh=
en it&#39;s not necessary, for example when only needing reading them.</div=
><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"> I mean as it is inspired by real use, can we have some of=
 them as example and some figures? i.e. under these conditions, the use of =
&quot;string_view&quot; in place of &quot;string&quot; resulted in a perfor=
mance improvement of x%, and a decrease of memory consumption of y%.<br>
</div></blockquote><div><br></div><div>I don&#39;t know any such benchmark =
but I don&#39;t see how adding copies would make algorithms not needing cop=
ies to be faster. I&#39;m not sure if it&#39;s necessary,</div><div>but I g=
uess you can request some comparison to the author.</div>
<div><br></div><div>Also, the other argument for string_view (previously st=
ring_ref) is that it can work with an array too, which is better than passi=
ng=A0</div><div>You&#39;ll find a long discussion on string_view in the arc=
hives of this forum.</div>
<div>=A0<br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0160b5e447943204e7715aa5--

.

--047d7b6777d6c9dc1304e7716afa
Content-Type: text/plain; charset=ISO-8859-1

Since the standard doesn't currently have an "immutable shared string"
type, I decided not to invent one in order to get noncopying views on it.
On Sep 28, 2013 8:00 AM, "Vincent Jacquet" <vjacquet@flowgroup.fr> wrote:

> I understand the handling part of a string as if it was a string, but
> "without doing memory allocation part". What I do not get is the
> "non-owning" part. I cannot reason locally because of this. Whenever I will
> use a string_view, I will have to think about the owner. For instance, I
> cannot store a string_view in a class or a container unless I am sure that
> the owner will be around longer than the instance this class or the
> container.
>
> If instead I define a type as "mutable range on an immutable shared
> string" (I call that a "stick", all puns intended and assumed), I can still
> provide trimming, truncating and slicing without memory allocation but I
> can also  guarante that the underlying string will not change ever (of
> course, under construction, my class will have to either take ownership of
> the string or create a unique copy). As a user of the class, I do not have
> to worry about the lifetime of the initial string. I can pass it around,
> even to other threads... I just find this safer.
>
> Thanks,
> Vincent
>
> On Saturday, September 28, 2013 2:09:08 PM UTC+2, Bjorn Reese wrote:
>>
>> On 09/28/2013 01:18 PM, Vincent Jacquet wrote:
>>
>> > Can someone point out use cases for this type?
>>
>> In one word: parsing.
>>
>> Most optimized parsers/lexers I am familiar with uses something
>> reminiscent of string_view.
>>
>> For example, if you need to parse an XML document then you need to
>> match start and end tags. With string_view you do not have to allocate
>> a string containing the end tag just to compare it to the start tag.
>>
>> String_view is also useful if you need to skip over parts of the
>> document without doing memory allocation.
>>
>>  --
>
> ---
> 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/.
>

--

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

--047d7b6777d6c9dc1304e7716afa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Since the standard doesn&#39;t currently have an &quot;immut=
able shared string&quot; type, I decided not to invent one in order to get =
noncopying views on it.</p>
<div class=3D"gmail_quote">On Sep 28, 2013 8:00 AM, &quot;Vincent Jacquet&q=
uot; &lt;<a href=3D"mailto:vjacquet@flowgroup.fr">vjacquet@flowgroup.fr</a>=
&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I understand the handling part of a string as if it was a =
string, but &quot;without doing memory allocation part&quot;. What I do not=
 get is the &quot;non-owning&quot; part. I cannot reason locally because of=
 this. Whenever I will use a string_view, I will have to think about the ow=
ner. For instance, I cannot store a string_view in a class or a container u=
nless I am sure that the owner will be around longer than the instance this=
 class or the container.<br>
<br>If instead I define a type as &quot;mutable range on an immutable share=
d string&quot; (I call that a &quot;stick&quot;, all puns intended and assu=
med), I can still provide trimming, truncating and slicing without memory a=
llocation but I can also=A0 guarante that the underlying string will not ch=
ange ever (of course, under construction, my class will have to either take=
 ownership of the string or create a unique copy). As a user of the class, =
I do not have to worry about the lifetime of the initial string. I can pass=
 it around, even to other threads... I just find this safer.<br>
<br>Thanks,<br>Vincent<br><br>On Saturday, September 28, 2013 2:09:08 PM UT=
C+2, Bjorn Reese wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/28/201=
3 01:18 PM, Vincent Jacquet wrote:
<br>
<br>&gt; Can someone point out use cases for this type?
<br>
<br>In one word: parsing.
<br>
<br>Most optimized parsers/lexers I am familiar with uses something
<br>reminiscent of string_view.
<br>
<br>For example, if you need to parse an XML document then you need to
<br>match start and end tags. With string_view you do not have to allocate
<br>a string containing the end tag just to compare it to the start tag.
<br>
<br>String_view is also useful if you need to skip over parts of the
<br>document without doing memory allocation.
<br>
<br></blockquote></div>

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b6777d6c9dc1304e7716afa--

.

--001a1133eaca8e825504e7716d49
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <vjacquet@flowgroup.fr>wrote:

> I understand the handling part of a string as if it was a string, but
> "without doing memory allocation part". What I do not get is the
> "non-owning" part. I cannot reason locally because of this. Whenever I will
> use a string_view, I will have to think about the owner. For instance, I
> cannot store a string_view in a class or a container unless I am sure that
> the owner will be around longer than the instance this class or the
> container.
>
>
You can store a string_view if you know it's refering to somehting that
never changes, but yes it's not designed for this I guess.
What you're asking would be for totally different use cases.

If I remember correctly, Ranges concept don't imply ownership anyway.

If instead I define a type as "mutable range on an immutable shared string"
> (I call that a "stick", all puns intended and assumed), I can still provide
> trimming, truncating and slicing without memory allocation but I can also
> guarante that the underlying string will not change ever (of course, under
> construction, my class will have to either take ownership of the string or
> create a unique copy). As a user of the class, I do not have to worry about
> the lifetime of the initial string. I can pass it around, even to other
> threads... I just find this safer.
>
>
What you seem to suggest is that you like to have something like a
string_view which is implicitely associated to, say a string or
stringbuffer, and works with the same guarantees than iterators?
I believe it's basically the same, but manipulating iterators or
string_view when invalidated because the source have changed is undefined
behaviour. I'm not sure if I'm 100% correct.
Do you have a problem with iterators in general too?

--

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

--001a1133eaca8e825504e7716d49
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <span dir=3D"ltr">=
&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flo=
wgroup.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">I understand the handling part of a strin=
g as if it was a string, but &quot;without doing memory allocation part&quo=
t;. What I do not get is the &quot;non-owning&quot; part. I cannot reason l=
ocally because of this. Whenever I will use a string_view, I will have to t=
hink about the owner. For instance, I cannot store a string_view in a class=
 or a container unless I am sure that the owner will be around longer than =
the instance this class or the container.<br>
<br></div></blockquote><div><br></div><div>You can store a string_view if y=
ou know it&#39;s refering to somehting that never changes, but yes it&#39;s=
 not designed for this I guess.</div><div>What you&#39;re asking would be f=
or totally different use cases.</div>
<div><br></div><div>If I remember correctly, Ranges concept don&#39;t imply=
 ownership anyway.=A0</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr">If instead I define a type as &quot;mutable range on an im=
mutable shared string&quot; (I call that a &quot;stick&quot;, all puns inte=
nded and assumed), I can still provide trimming, truncating and slicing wit=
hout memory allocation but I can also=A0 guarante that the underlying strin=
g will not change ever (of course, under construction, my class will have t=
o either take ownership of the string or create a unique copy). As a user o=
f the class, I do not have to worry about the lifetime of the initial strin=
g. I can pass it around, even to other threads... I just find this safer.<b=
r>
<br></div></blockquote><div><br></div><div>What you seem to suggest is that=
 you like to have something like a string_view which is implicitely associa=
ted to, say a string or stringbuffer, and works with the same guarantees th=
an iterators?<br>
I believe it&#39;s basically the same, but manipulating iterators or string=
_view when invalidated because the source have changed is undefined behavio=
ur. I&#39;m not sure if I&#39;m 100% correct.<br>Do you have a problem with=
 iterators in general too?</div>
<div>=A0=A0<br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a1133eaca8e825504e7716d49--

.

------=_Part_1164_20773269.1380379057723
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The iterator is returned by the string. Unless I am mistaken, the=20
string_view is not. Therefore the string knows when it returns an iterator.=
=20
It does not even know when a string_view references it. It does not feel=20
right. I mean, I'm okay with lending a pen. But if someone takes it without=
=20
telling me, I'll call him a thief.

Also the iterator is a concept we are taught about. I know I have to=20
manipulate it with care - mostly because it is so much like a pointer.
The string_view looks harmless. Once I am done with the parsing, let's put=
=20
the substring in a vector. Cool, there is not extra copy. So easy. And=20
potentially so wrong.

It guess it proved to be fine to use this in applications where the context=
=20
of use is under control. But is it still ok in a standard library anyone=20
could use?


On Saturday, September 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=EBl Lamotte=20
wrote:
>
>
>
>
> On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <vjac...@flowgroup.fr<ja=
vascript:>
> > wrote:
>
>> I understand the handling part of a string as if it was a string, but=20
>> "without doing memory allocation part". What I do not get is the=20
>> "non-owning" part. I cannot reason locally because of this. Whenever I w=
ill=20
>> use a string_view, I will have to think about the owner. For instance, I=
=20
>> cannot store a string_view in a class or a container unless I am sure th=
at=20
>> the owner will be around longer than the instance this class or the=20
>> container.
>>
>>
> You can store a string_view if you know it's refering to somehting that=
=20
> never changes, but yes it's not designed for this I guess.
> What you're asking would be for totally different use cases.
>
> If I remember correctly, Ranges concept don't imply ownership anyway.=20
>
> If instead I define a type as "mutable range on an immutable shared=20
>> string" (I call that a "stick", all puns intended and assumed), I can st=
ill=20
>> provide trimming, truncating and slicing without memory allocation but I=
=20
>> can also  guarante that the underlying string will not change ever (of=
=20
>> course, under construction, my class will have to either take ownership =
of=20
>> the string or create a unique copy). As a user of the class, I do not ha=
ve=20
>> to worry about the lifetime of the initial string. I can pass it around,=
=20
>> even to other threads... I just find this safer.
>>
>>
> What you seem to suggest is that you like to have something like a=20
> string_view which is implicitely associated to, say a string or=20
> stringbuffer, and works with the same guarantees than iterators?
> I believe it's basically the same, but manipulating iterators or=20
> string_view when invalidated because the source have changed is undefined=
=20
> behaviour. I'm not sure if I'm 100% correct.
> Do you have a problem with iterators in general too?
>  =20
>

--=20

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

------=_Part_1164_20773269.1380379057723
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The iterator is returned by the string. Unless I am mistak=
en, the string_view is not. Therefore the string knows when it returns an i=
terator. It does not even know when a string_view references it. It does no=
t feel right. I mean, I'm okay with lending a pen. But if someone takes it =
without telling me, I'll call him a thief.<br><br>Also the iterator is a co=
ncept we are taught about. I know I have to manipulate it with care - mostl=
y because it is so much like a pointer.<br>The string_view looks harmless. =
Once I am done with the parsing, let's put the substring in a vector. Cool,=
 there is not extra copy. So easy. And potentially so wrong.<br><br>It gues=
s it proved to be fine to use this in applications where the context of use=
 is under control. But is it still ok in a standard library anyone could us=
e?<br><br><br>On Saturday, September 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=
=EBl Lamotte 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"><br><div><br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 3=
:00 PM, Vincent Jacquet <span dir=3D"ltr">&lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"yhtEcC2goqoJ">vjac...@flowgroup.fr</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">I understand the handling part of a strin=
g as if it was a string, but "without doing memory allocation part". What I=
 do not get is the "non-owning" part. I cannot reason locally because of th=
is. Whenever I will use a string_view, I will have to think about the owner=
.. For instance, I cannot store a string_view in a class or a container unle=
ss I am sure that the owner will be around longer than the instance this cl=
ass or the container.<br>
<br></div></blockquote><div><br></div><div>You can store a string_view if y=
ou know it's refering to somehting that never changes, but yes it's not des=
igned for this I guess.</div><div>What you're asking would be for totally d=
ifferent use cases.</div>
<div><br></div><div>If I remember correctly, Ranges concept don't imply own=
ership anyway.&nbsp;</div><div><br></div><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">
<div dir=3D"ltr">If instead I define a type as "mutable range on an immutab=
le shared string" (I call that a "stick", all puns intended and assumed), I=
 can still provide trimming, truncating and slicing without memory allocati=
on but I can also&nbsp; guarante that the underlying string will not change=
 ever (of course, under construction, my class will have to either take own=
ership of the string or create a unique copy). As a user of the class, I do=
 not have to worry about the lifetime of the initial string. I can pass it =
around, even to other threads... I just find this safer.<br>
<br></div></blockquote><div><br></div><div>What you seem to suggest is that=
 you like to have something like a string_view which is implicitely associa=
ted to, say a string or stringbuffer, and works with the same guarantees th=
an iterators?<br>
I believe it's basically the same, but manipulating iterators or string_vie=
w when invalidated because the source have changed is undefined behaviour. =
I'm not sure if I'm 100% correct.<br>Do you have a problem with iterators i=
n general too?</div>
<div>&nbsp;&nbsp;<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1164_20773269.1380379057723--

.

--047d7bd77058a93bb704e772cc85
Content-Type: text/plain; charset=ISO-8859-1

On 28 September 2013 09:37, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

> The string_view looks harmless.
>

Should I assume that you rarely pass anything by reference, because that
suffers from the same issue?  Besides the usual dangers when using
reference semantics, what is the objection?

(Yeah, I preferred the name string_ref, but the committee as a whole
preferred string_view.  Such is life.)

IMO, it is needed.  "Strings" come from many different sources
(std::string, std::vector<char>, C-literals, third party APIs, etc.), and
it shows up in libraries with a variety of spellings.  I would much rather
use string_view in my interfaces than hard-coding a specific string type.
--
 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/.

--047d7bd77058a93bb704e772cc85
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 28 September 2013 09:37, Vincent Jacquet <span dir=3D"l=
tr">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet=
@flowgroup.fr</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The string_view looks harml=
ess.</div></blockquote><div>=A0</div><div>Should I assume that you rarely p=
ass anything by reference, because that suffers from the same issue? =A0Bes=
ides the usual dangers when using reference semantics, what is the objectio=
n?</div>

<div><br></div><div>(Yeah, I preferred the name string_ref, but the committ=
ee as a whole preferred string_view. =A0Such is life.)</div><div><br></div>=
<div>IMO, it is needed. =A0&quot;Strings&quot; come from many different sou=
rces (std::string, std::vector&lt;char&gt;, C-literals, third party APIs, e=
tc.), and it shows up in libraries with a variety of spellings. =A0I would =
much rather use string_view in my interfaces than hard-coding a specific st=
ring type.</div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bd77058a93bb704e772cc85--

.

------=_Part_345_18648453.1380380471533
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It is the other way around: it is not what I am using, it is what I am=20
defining. Because the type is taking ownership of the string, it can do=20
whatever it wants with it, such as preventing modification and sharing it.=
=20
A (very) na=EFve implementation could use shared_ptr<const string>.

But this is exactly what I see as a problem in your proposal: because the=
=20
standard does not have an immutable shared string, I cannot reason locally=
=20
when using string_view. Once I created a string_view I have to make sure I=
=20
do not change or destroy the original string, in any path, any threads, as=
=20
long as this view, or any other created from it, still exists. Because the=
=20
type is not taking this responsability, it is becoming mine.

On Saturday, September 28, 2013 3:16:55 PM UTC+2, Jeffrey Yasskin wrote:
>
> Since the standard doesn't currently have an "immutable shared string"=20
> type, I decided not to invent one in order to get noncopying views on it.
> On Sep 28, 2013 8:00 AM, "Vincent Jacquet" <vjac...@flowgroup.fr<javascri=
pt:>>=20
> wrote:
>
>> I understand the handling part of a string as if it was a string, but=20
>> "without doing memory allocation part". What I do not get is the=20
>> "non-owning" part. I cannot reason locally because of this. Whenever I w=
ill=20
>> use a string_view, I will have to think about the owner. For instance, I=
=20
>> cannot store a string_view in a class or a container unless I am sure th=
at=20
>> the owner will be around longer than the instance this class or the=20
>> container.
>>
>> If instead I define a type as "mutable range on an immutable shared=20
>> string" (I call that a "stick", all puns intended and assumed), I can st=
ill=20
>> provide trimming, truncating and slicing without memory allocation but I=
=20
>> can also  guarante that the underlying string will not change ever (of=
=20
>> course, under construction, my class will have to either take ownership =
of=20
>> the string or create a unique copy). As a user of the class, I do not ha=
ve=20
>> to worry about the lifetime of the initial string. I can pass it around,=
=20
>> even to other threads... I just find this safer.
>>
>> Thanks,
>> Vincent
>>
>> On Saturday, September 28, 2013 2:09:08 PM UTC+2, Bjorn Reese wrote:
>>>
>>> On 09/28/2013 01:18 PM, Vincent Jacquet wrote:=20
>>>
>>> > Can someone point out use cases for this type?=20
>>>
>>> In one word: parsing.=20
>>>
>>> Most optimized parsers/lexers I am familiar with uses something=20
>>> reminiscent of string_view.=20
>>>
>>> For example, if you need to parse an XML document then you need to=20
>>> match start and end tags. With string_view you do not have to allocate=
=20
>>> a string containing the end tag just to compare it to the start tag.=20
>>>
>>> String_view is also useful if you need to skip over parts of the=20
>>> document without doing memory allocation.=20
>>>
>>>  --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>

--=20

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

------=_Part_345_18648453.1380380471533
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It is the other way around: it is not what I am using, it =
is what I am defining. Because the type is taking ownership of the string, =
it can do whatever it wants with it, such as preventing modification and sh=
aring it. A (very) na=EFve implementation could use shared_ptr&lt;const str=
ing&gt;.<br><br>But this is exactly what I see as a problem in your proposa=
l: because the standard does not have an immutable shared string, I cannot =
reason locally when using string_view. Once I created a string_view I have =
to make sure I do not change or destroy the original string, in any path, a=
ny threads, as long as this view, or any other created from it, still exist=
s. Because the type is not taking this responsability, it is becoming mine.=
<br><br>On Saturday, September 28, 2013 3:16:55 PM UTC+2, Jeffrey Yasskin w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">Since the =
standard doesn't currently have an "immutable shared string" type, I decide=
d not to invent one in order to get noncopying views on it.</p>
<div class=3D"gmail_quote">On Sep 28, 2013 8:00 AM, "Vincent Jacquet" &lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"jY2TlF-U7=
bYJ">vjac...@flowgroup.fr</a>&gt; wrote:<br type=3D"attribution"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div dir=3D"ltr">I understand the handling part of a string as if it was a =
string, but "without doing memory allocation part". What I do not get is th=
e "non-owning" part. I cannot reason locally because of this. Whenever I wi=
ll use a string_view, I will have to think about the owner. For instance, I=
 cannot store a string_view in a class or a container unless I am sure that=
 the owner will be around longer than the instance this class or the contai=
ner.<br>
<br>If instead I define a type as "mutable range on an immutable shared str=
ing" (I call that a "stick", all puns intended and assumed), I can still pr=
ovide trimming, truncating and slicing without memory allocation but I can =
also&nbsp; guarante that the underlying string will not change ever (of cou=
rse, under construction, my class will have to either take ownership of the=
 string or create a unique copy). As a user of the class, I do not have to =
worry about the lifetime of the initial string. I can pass it around, even =
to other threads... I just find this safer.<br>
<br>Thanks,<br>Vincent<br><br>On Saturday, September 28, 2013 2:09:08 PM UT=
C+2, Bjorn Reese wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/28/201=
3 01:18 PM, Vincent Jacquet wrote:
<br>
<br>&gt; Can someone point out use cases for this type?
<br>
<br>In one word: parsing.
<br>
<br>Most optimized parsers/lexers I am familiar with uses something
<br>reminiscent of string_view.
<br>
<br>For example, if you need to parse an XML document then you need to
<br>match start and end tags. With string_view you do not have to allocate
<br>a string containing the end tag just to compare it to the start tag.
<br>
<br>String_view is also useful if you need to skip over parts of the
<br>document without doing memory allocation.
<br>
<br></blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
jY2TlF-U7bYJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"jY2TlF-U7bYJ">std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_345_18648453.1380380471533--

.

------=_Part_1145_17168570.1380380975556
Content-Type: text/plain; charset=ISO-8859-1



Il giorno sabato 28 settembre 2013 17:01:11 UTC+2, Vincent Jacquet ha
scritto:
>
> Once I created a string_view I have to make sure I do not change or
> destroy the original string, in any path, any threads, as long as this
> view, or any other created from it, still exists. Because the type is not
> taking this responsability, it is becoming mine.
>

supposing the string_view(string const&) constructor cheap as it should be
(IMO), then you can simply construct the string_view from your shared_ptr
as needed, instead of storing it as a class member. With proper RAII there
should be no risk whatsoever ...

--

---
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_1145_17168570.1380380975556
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Il giorno sabato 28 settembre 2013 17:01:11 UTC+2,=
 Vincent Jacquet ha scritto:<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">Once I created a string_view I have to make sure I do not ch=
ange or destroy the original string, in any path, any threads, as long as t=
his view, or any other created from it, still exists. Because the type is n=
ot taking this responsability, it is becoming mine.<br></div></blockquote><=
div><br>supposing the string_view(string const&amp;) constructor cheap as i=
t should be (IMO), then you can simply construct the string_view from your =
shared_ptr as needed, instead of storing it as a class member. With proper =
RAII there should be no risk whatsoever ... <br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1145_17168570.1380380975556--

.

------=_Part_0_1380383537095
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Non ownership is quite common in real world designs. I've had several place=
s where there was e.g. a vector of unique_ptr, and several other indexing c=
ontainers storing raw pointers. There is no issue about ownership reasoning=
 because the owning and nonowning containers are part of the same class.

Iterators already are nonowning entities used everywhere, in most programmi=
ng languages of which I am aware.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Vincent Jacquet" <vjacquet@flowgroup.fr>
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Use cases for string_view (N3762)?
Date: Sat, Sep 28, 2013 6:00 AM

I understand the handling part of a string as if it was a string, but "with=
out doing memory allocation part". What I do not get is the "non-owning" pa=
rt. I cannot reason locally because of this. Whenever I will use a string_v=
iew, I will have to think about the owner. For instance, I cannot store a s=
tring_view in a class or a container unless I am sure that the owner will b=
e around longer than the instance this class or the container.

If instead I define a type as "mutable range on an immutable shared string"=
 (I call that a "stick", all puns intended and assumed), I can still provid=
e trimming, truncating and slicing without memory allocation but I can also=
  guarante that the underlying string will not change ever (of course, unde=
r construction, my class will have to either take ownership of the string o=
r create a unique copy). As a user of the class, I do not have to worry abo=
ut the lifetime of the initial string. I can pass it around, even to other =
threads... I just find this safer.

Thanks,
Vincent

On Saturday, September 28, 2013 2:09:08 PM UTC+2, Bjorn Reese wrote:On 09/2=
8/2013 01:18 PM, Vincent Jacquet wrote:



> Can someone point out use cases for this type?



In one word: parsing.



Most optimized parsers/lexers I am familiar with uses something

reminiscent of string_view.



For example, if you need to parse an XML document then you need to

match start and end tags. With string_view you do not have to allocate

a string containing the end tag just to compare it to the start tag.



String_view is also useful if you need to skip over parts of the

document without doing memory allocation.








--=20

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

--=20

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

------=_Part_0_1380383537095
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>Non o=
wnership is quite common in real world designs. I've had several places whe=
re there was e.g. a vector of unique_ptr, and several other indexing contai=
ners storing raw pointers. There is no issue about ownership reasoning beca=
use the owning and nonowning containers are part of the same class.</div><d=
iv><br></div><div>Iterators already are nonowning entities used everywhere,=
 in most programming languages of which I am aware.</div><div><br></div><di=
v>Sent from a touchscreen. Please excuse the brevity and tpyos.</div><br><d=
iv id=3D"htc_header">----- Reply message -----<br>From: &quot;Vincent Jacqu=
et&quot; &lt;vjacquet@flowgroup.fr&gt;<br>To: &lt;std-proposals@isocpp.org&=
gt;<br>Subject: [std-proposals] Use cases for string_view (N3762)?<br>Date:=
 Sat, Sep 28, 2013 6:00 AM</div></div><br><div dir=3D"ltr">I understand the=
 handling part of a string as if it was a string, but "without doing memory=
 allocation part". What I do not get is the "non-owning" part. I cannot rea=
son locally because of this. Whenever I will use a string_view, I will have=
 to think about the owner. For instance, I cannot store a string_view in a =
class or a container unless I am sure that the owner will be around longer =
than the instance this class or the container.<br><br>If instead I define a=
 type as "mutable range on an immutable shared string" (I call that a "stic=
k", all puns intended and assumed), I can still provide trimming, truncatin=
g and slicing without memory allocation but I can also&nbsp; guarante that =
the underlying string will not change ever (of course, under construction, =
my class will have to either take ownership of the string or create a uniqu=
e copy). As a user of the class, I do not have to worry about the lifetime =
of the initial string. I can pass it around, even to other threads... I jus=
t find this safer.<br><br>Thanks,<br>Vincent<br><br>On Saturday, September =
28, 2013 2:09:08 PM UTC+2, Bjorn Reese wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On 09/28/2013 01:18 PM, Vincent Jacquet wrote:
<br>
<br>&gt; Can someone point out use cases for this type?
<br>
<br>In one word: parsing.
<br>
<br>Most optimized parsers/lexers I am familiar with uses something
<br>reminiscent of string_view.
<br>
<br>For example, if you need to parse an XML document then you need to
<br>match start and end tags. With string_view you do not have to allocate
<br>a string containing the end tag just to compare it to the start tag.
<br>
<br>String_view is also useful if you need to skip over parts of the
<br>document without doing memory allocation.
<br>
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_0_1380383537095--


.

------=_Part_0_1380383717421
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Perhaps, but the string does not actually know about its iterators. Just be=
cause it returns them does not mean it keeps track of them.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Vincent Jacquet" <vjacquet@flowgroup.fr>
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Use cases for string_view (N3762)?
Date: Sat, Sep 28, 2013 7:37 AM

The iterator is returned by the string. Unless I am mistaken, the string_vi=
ew is not. Therefore the string knows when it returns an iterator. It does =
not even know when a string_view references it. It does not feel right. I m=
ean, I'm okay with lending a pen. But if someone takes it without telling m=
e, I'll call him a thief.

Also the iterator is a concept we are taught about. I know I have to manipu=
late it with care - mostly because it is so much like a pointer.
The string_view looks harmless. Once I am done with the parsing, let's put =
the substring in a vector. Cool, there is not extra copy. So easy. And pote=
ntially so wrong.

It guess it proved to be fine to use this in applications where the context=
 of use is under control. But is it still ok in a standard library anyone c=
ould use?


On Saturday, September 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=EBl Lamotte wr=
ote:


On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <vjac...@flowgroup.fr> wro=
te:

I understand the handling part of a string as if it was a string, but "with=
out doing memory allocation part". What I do not get is the "non-owning" pa=
rt. I cannot reason locally because of this. Whenever I will use a string_v=
iew, I will have to think about the owner. For instance, I cannot store a s=
tring_view in a class or a container unless I am sure that the owner will b=
e around longer than the instance this class or the container.



You can store a string_view if you know it's refering to somehting that nev=
er changes, but yes it's not designed for this I guess.
What you're asking would be for totally different use cases.


If I remember correctly, Ranges concept don't imply ownership anyway.=20


If instead I define a type as "mutable range on an immutable shared string"=
 (I call that a "stick", all puns intended and assumed), I can still provid=
e trimming, truncating and slicing without memory allocation but I can also=
  guarante that the underlying string will not change ever (of course, unde=
r construction, my class will have to either take ownership of the string o=
r create a unique copy). As a user of the class, I do not have to worry abo=
ut the lifetime of the initial string. I can pass it around, even to other =
threads... I just find this safer.



What you seem to suggest is that you like to have something like a string_v=
iew which is implicitely associated to, say a string or stringbuffer, and w=
orks with the same guarantees than iterators?

I believe it's basically the same, but manipulating iterators or string_vie=
w when invalidated because the source have changed is undefined behaviour. =
I'm not sure if I'm 100% correct.
Do you have a problem with iterators in general too?










--=20

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

--=20

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

------=_Part_0_1380383717421
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>Perha=
ps, but the string does not actually know about its iterators. Just because=
 it returns them does not mean it keeps track of them.</div><div><br></div>=
<div>Sent from a touchscreen. Please excuse the brevity and tpyos.</div><br=
><div id=3D"htc_header">----- Reply message -----<br>From: &quot;Vincent Ja=
cquet&quot; &lt;vjacquet@flowgroup.fr&gt;<br>To: &lt;std-proposals@isocpp.o=
rg&gt;<br>Subject: [std-proposals] Use cases for string_view (N3762)?<br>Da=
te: Sat, Sep 28, 2013 7:37 AM</div></div><br><div dir=3D"ltr">The iterator =
is returned by the string. Unless I am mistaken, the string_view is not. Th=
erefore the string knows when it returns an iterator. It does not even know=
 when a string_view references it. It does not feel right. I mean, I'm okay=
 with lending a pen. But if someone takes it without telling me, I'll call =
him a thief.<br><br>Also the iterator is a concept we are taught about. I k=
now I have to manipulate it with care - mostly because it is so much like a=
 pointer.<br>The string_view looks harmless. Once I am done with the parsin=
g, let's put the substring in a vector. Cool, there is not extra copy. So e=
asy. And potentially so wrong.<br><br>It guess it proved to be fine to use =
this in applications where the context of use is under control. But is it s=
till ok in a standard library anyone could use?<br><br><br>On Saturday, Sep=
tember 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=EBl Lamotte wrote:<blockquote =
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"><br><div><br><br><div cla=
ss=3D"gmail_quote">On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"yhtEcC2goqoJ">vjac...@flowgroup.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">I understand the handling part of a strin=
g as if it was a string, but "without doing memory allocation part". What I=
 do not get is the "non-owning" part. I cannot reason locally because of th=
is. Whenever I will use a string_view, I will have to think about the owner=
.. For instance, I cannot store a string_view in a class or a container unle=
ss I am sure that the owner will be around longer than the instance this cl=
ass or the container.<br>
<br></div></blockquote><div><br></div><div>You can store a string_view if y=
ou know it's refering to somehting that never changes, but yes it's not des=
igned for this I guess.</div><div>What you're asking would be for totally d=
ifferent use cases.</div>
<div><br></div><div>If I remember correctly, Ranges concept don't imply own=
ership anyway.&nbsp;</div><div><br></div><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">
<div dir=3D"ltr">If instead I define a type as "mutable range on an immutab=
le shared string" (I call that a "stick", all puns intended and assumed), I=
 can still provide trimming, truncating and slicing without memory allocati=
on but I can also&nbsp; guarante that the underlying string will not change=
 ever (of course, under construction, my class will have to either take own=
ership of the string or create a unique copy). As a user of the class, I do=
 not have to worry about the lifetime of the initial string. I can pass it =
around, even to other threads... I just find this safer.<br>
<br></div></blockquote><div><br></div><div>What you seem to suggest is that=
 you like to have something like a string_view which is implicitely associa=
ted to, say a string or stringbuffer, and works with the same guarantees th=
an iterators?<br>
I believe it's basically the same, but manipulating iterators or string_vie=
w when invalidated because the source have changed is undefined behaviour. =
I'm not sure if I'm 100% correct.<br>Do you have a problem with iterators i=
n general too?</div>
<div>&nbsp;&nbsp;<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_0_1380383717421--


.

------=_Part_0_1380383812604
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Not to mention, in a language with const, which declares immutablity, there=
 is little reason for a separate immutable type. I'd you want immutable sem=
antics, just add const.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Jeffrey Yasskin" <jyasskin@google.com>
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Use cases for string_view (N3762)?
Date: Sat, Sep 28, 2013 6:16 AM

Since the standard doesn't currently have an "immutable shared string" type=
, I decided not to invent one in order to get noncopying views on it.
On Sep 28, 2013 8:00 AM, "Vincent Jacquet" <vjacquet@flowgroup.fr> wrote:
I understand the handling part of a string as if it was a string, but "with=
out doing memory allocation part". What I do not get is the "non-owning" pa=
rt. I cannot reason locally because of this. Whenever I will use a string_v=
iew, I will have to think about the owner. For instance, I cannot store a s=
tring_view in a class or a container unless I am sure that the owner will b=
e around longer than the instance this class or the container.


If instead I define a type as "mutable range on an immutable shared string"=
 (I call that a "stick", all puns intended and assumed), I can still provid=
e trimming, truncating and slicing without memory allocation but I can also=
=A0 guarante that the underlying string will not change ever (of course, un=
der construction, my class will have to either take ownership of the string=
 or create a unique copy). As a user of the class, I do not have to worry a=
bout the lifetime of the initial string. I can pass it around, even to othe=
r threads... I just find this safer.


Thanks,
Vincent

On Saturday, September 28, 2013 2:09:08 PM UTC+2, Bjorn Reese wrote:On 09/2=
8/2013 01:18 PM, Vincent Jacquet wrote:



> Can someone point out use cases for this type?



In one word: parsing.



Most optimized parsers/lexers I am familiar with uses something

reminiscent of string_view.



For example, if you need to parse an XML document then you need to

match start and end tags. With string_view you do not have to allocate

a string containing the end tag just to compare it to the start tag.



String_view is also useful if you need to skip over parts of the

document without doing memory allocation.








--=20

=A0

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

Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.






--=20

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

--=20

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

------=_Part_0_1380383812604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>Not t=
o mention, in a language with const, which declares immutablity, there is l=
ittle reason for a separate immutable type. I'd you want immutable semantic=
s, just add const.</div><div><br></div><div>Sent from a touchscreen. Please=
 excuse the brevity and tpyos.</div><br><div id=3D"htc_header">----- Reply =
message -----<br>From: &quot;Jeffrey Yasskin&quot; &lt;jyasskin@google.com&=
gt;<br>To: &lt;std-proposals@isocpp.org&gt;<br>Subject: [std-proposals] Use=
 cases for string_view (N3762)?<br>Date: Sat, Sep 28, 2013 6:16 AM</div></d=
iv><br><p dir=3D"ltr">Since the standard doesn&#39;t currently have an &quo=
t;immutable shared string&quot; type, I decided not to invent one in order =
to get noncopying views on it.</p>
<div class=3D"gmail_quote">On Sep 28, 2013 8:00 AM, &quot;Vincent Jacquet&q=
uot; &lt;<a href=3D"mailto:vjacquet@flowgroup.fr">vjacquet@flowgroup.fr</a>=
&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I understand the handling part of a string as if it was a =
string, but &quot;without doing memory allocation part&quot;. What I do not=
 get is the &quot;non-owning&quot; part. I cannot reason locally because of=
 this. Whenever I will use a string_view, I will have to think about the ow=
ner. For instance, I cannot store a string_view in a class or a container u=
nless I am sure that the owner will be around longer than the instance this=
 class or the container.<br>
<br>If instead I define a type as &quot;mutable range on an immutable share=
d string&quot; (I call that a &quot;stick&quot;, all puns intended and assu=
med), I can still provide trimming, truncating and slicing without memory a=
llocation but I can also=A0 guarante that the underlying string will not ch=
ange ever (of course, under construction, my class will have to either take=
 ownership of the string or create a unique copy). As a user of the class, =
I do not have to worry about the lifetime of the initial string. I can pass=
 it around, even to other threads... I just find this safer.<br>
<br>Thanks,<br>Vincent<br><br>On Saturday, September 28, 2013 2:09:08 PM UT=
C+2, Bjorn Reese wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/28/201=
3 01:18 PM, Vincent Jacquet wrote:
<br>
<br>&gt; Can someone point out use cases for this type?
<br>
<br>In one word: parsing.
<br>
<br>Most optimized parsers/lexers I am familiar with uses something
<br>reminiscent of string_view.
<br>
<br>For example, if you need to parse an XML document then you need to
<br>match start and end tags. With string_view you do not have to allocate
<br>a string containing the end tag just to compare it to the start tag.
<br>
<br>String_view is also useful if you need to skip over parts of the
<br>document without doing memory allocation.
<br>
<br></blockquote></div>

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_0_1380383812604--


.

------=_Part_1291_21004727.1380384512413
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

no, but it *could*. That's the point.

On Saturday, September 28, 2013 5:55:17 PM UTC+2, Billy O'Neal wrote:
>
> Perhaps, but the string does not actually know about its iterators. Just=
=20
> because it returns them does not mean it keeps track of them.
>
> Sent from a touchscreen. Please excuse the brevity and tpyos.
>
> ----- Reply message -----
> From: "Vincent Jacquet" <vjac...@flowgroup.fr <javascript:>>
> To: <std-pr...@isocpp.org <javascript:>>
> Subject: [std-proposals] Use cases for string_view (N3762)?
> Date: Sat, Sep 28, 2013 7:37 AM
>
> The iterator is returned by the string. Unless I am mistaken, the=20
> string_view is not. Therefore the string knows when it returns an iterato=
r.=20
> It does not even know when a string_view references it. It does not feel=
=20
> right. I mean, I'm okay with lending a pen. But if someone takes it witho=
ut=20
> telling me, I'll call him a thief.
>
> Also the iterator is a concept we are taught about. I know I have to=20
> manipulate it with care - mostly because it is so much like a pointer.
> The string_view looks harmless. Once I am done with the parsing, let's pu=
t=20
> the substring in a vector. Cool, there is not extra copy. So easy. And=20
> potentially so wrong.
>
> It guess it proved to be fine to use this in applications where the=20
> context of use is under control. But is it still ok in a standard library=
=20
> anyone could use?
>
>
> On Saturday, September 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=EBl Lamotte=
=20
> wrote:
>>
>>
>>
>>
>> On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <vjac...@flowgroup.fr>w=
rote:
>>
>>> I understand the handling part of a string as if it was a string, but=
=20
>>> "without doing memory allocation part". What I do not get is the=20
>>> "non-owning" part. I cannot reason locally because of this. Whenever I =
will=20
>>> use a string_view, I will have to think about the owner. For instance, =
I=20
>>> cannot store a string_view in a class or a container unless I am sure t=
hat=20
>>> the owner will be around longer than the instance this class or the=20
>>> container.
>>>
>>>
>> You can store a string_view if you know it's refering to somehting that=
=20
>> never changes, but yes it's not designed for this I guess.
>> What you're asking would be for totally different use cases.
>>
>> If I remember correctly, Ranges concept don't imply ownership anyway.=20
>>
>> If instead I define a type as "mutable range on an immutable shared=20
>>> string" (I call that a "stick", all puns intended and assumed), I can s=
till=20
>>> provide trimming, truncating and slicing without memory allocation but =
I=20
>>> can also  guarante that the underlying string will not change ever (of=
=20
>>> course, under construction, my class will have to either take ownership=
 of=20
>>> the string or create a unique copy). As a user of the class, I do not h=
ave=20
>>> to worry about the lifetime of the initial string. I can pass it around=
,=20
>>> even to other threads... I just find this safer.
>>>
>>>
>> What you seem to suggest is that you like to have something like a=20
>> string_view which is implicitely associated to, say a string or=20
>> stringbuffer, and works with the same guarantees than iterators?
>> I believe it's basically the same, but manipulating iterators or=20
>> string_view when invalidated because the source have changed is undefine=
d=20
>> behaviour. I'm not sure if I'm 100% correct.
>> Do you have a problem with iterators in general too?
>>  =20
>>
>  --=20
> =20
> ---=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

------=_Part_1291_21004727.1380384512413
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">no, but it <i>could</i>. That's the point.<br><br>On Satur=
day, September 28, 2013 5:55:17 PM UTC+2, Billy O'Neal wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div style=3D"font-size:12pt;font-family:Cal=
ibri,sans-serif"><div>Perhaps, but the string does not actually know about =
its iterators. Just because it returns them does not mean it keeps track of=
 them.</div><div><br></div><div>Sent from a touchscreen. Please excuse the =
brevity and tpyos.</div><br><div>----- Reply message -----<br>From: "Vincen=
t Jacquet" &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"y4kebZJUC_wJ">vjac...@flowgroup.fr</a>&gt;<br>To: &lt;<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"y4kebZJUC_wJ">std-pr..=
..@isocpp.org</a>&gt;<br>Subject: [std-proposals] Use cases for string_view =
(N3762)?<br>Date: Sat, Sep 28, 2013 7:37 AM</div></div><br><div dir=3D"ltr"=
>The iterator is returned by the string. Unless I am mistaken, the string_v=
iew is not. Therefore the string knows when it returns an iterator. It does=
 not even know when a string_view references it. It does not feel right. I =
mean, I'm okay with lending a pen. But if someone takes it without telling =
me, I'll call him a thief.<br><br>Also the iterator is a concept we are tau=
ght about. I know I have to manipulate it with care - mostly because it is =
so much like a pointer.<br>The string_view looks harmless. Once I am done w=
ith the parsing, let's put the substring in a vector. Cool, there is not ex=
tra copy. So easy. And potentially so wrong.<br><br>It guess it proved to b=
e fine to use this in applications where the context of use is under contro=
l. But is it still ok in a standard library anyone could use?<br><br><br>On=
 Saturday, September 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=EBl Lamotte wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><br=
><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacque=
t <span dir=3D"ltr">&lt;<a>vjac...@flowgroup.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">I understand the handling part of a strin=
g as if it was a string, but "without doing memory allocation part". What I=
 do not get is the "non-owning" part. I cannot reason locally because of th=
is. Whenever I will use a string_view, I will have to think about the owner=
.. For instance, I cannot store a string_view in a class or a container unle=
ss I am sure that the owner will be around longer than the instance this cl=
ass or the container.<br>
<br></div></blockquote><div><br></div><div>You can store a string_view if y=
ou know it's refering to somehting that never changes, but yes it's not des=
igned for this I guess.</div><div>What you're asking would be for totally d=
ifferent use cases.</div>
<div><br></div><div>If I remember correctly, Ranges concept don't imply own=
ership anyway.&nbsp;</div><div><br></div><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">
<div dir=3D"ltr">If instead I define a type as "mutable range on an immutab=
le shared string" (I call that a "stick", all puns intended and assumed), I=
 can still provide trimming, truncating and slicing without memory allocati=
on but I can also&nbsp; guarante that the underlying string will not change=
 ever (of course, under construction, my class will have to either take own=
ership of the string or create a unique copy). As a user of the class, I do=
 not have to worry about the lifetime of the initial string. I can pass it =
around, even to other threads... I just find this safer.<br>
<br></div></blockquote><div><br></div><div>What you seem to suggest is that=
 you like to have something like a string_view which is implicitely associa=
ted to, say a string or stringbuffer, and works with the same guarantees th=
an iterators?<br>
I believe it's basically the same, but manipulating iterators or string_vie=
w when invalidated because the source have changed is undefined behaviour. =
I'm not sure if I'm 100% correct.<br>Do you have a problem with iterators i=
n general too?</div>
<div>&nbsp;&nbsp;<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
y4kebZJUC_wJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"y4kebZJUC_wJ">std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1291_21004727.1380384512413--

.

------=_Part_1118_23446047.1380384562995
Content-Type: text/plain; charset=ISO-8859-1

I agree, this is why the type I briefly defined is not const: it is mutable
on the boundaries. I can truncate simply by adjusting its length (not the
one of the string is it referring to).


On Saturday, September 28, 2013 5:56:52 PM UTC+2, Billy O'Neal wrote:
>
> Not to mention, in a language with const, which declares immutablity,
> there is little reason for a separate immutable type. I'd you want
> immutable semantics, just add const.
>
> Sent from a touchscreen. Please excuse the brevity and tpyos.
>
> ----- Reply message -----
> From: "Jeffrey Yasskin" <jyas...@google.com <javascript:>>
> To: <std-pr...@isocpp.org <javascript:>>
> Subject: [std-proposals] Use cases for string_view (N3762)?
> Date: Sat, Sep 28, 2013 6:16 AM
>
> Since the standard doesn't currently have an "immutable shared string"
> type, I decided not to invent one in order to get noncopying views on it.
> On Sep 28, 2013 8:00 AM, "Vincent Jacquet" <vjac...@flowgroup.fr<javascript:>>
> wrote:
>
>> I understand the handling part of a string as if it was a string, but
>> "without doing memory allocation part". What I do not get is the
>> "non-owning" part. I cannot reason locally because of this. Whenever I will
>> use a string_view, I will have to think about the owner. For instance, I
>> cannot store a string_view in a class or a container unless I am sure that
>> the owner will be around longer than the instance this class or the
>> container.
>>
>> If instead I define a type as "mutable range on an immutable shared
>> string" (I call that a "stick", all puns intended and assumed), I can still
>> provide trimming, truncating and slicing without memory allocation but I
>> can also  guarante that the underlying string will not change ever (of
>> course, under construction, my class will have to either take ownership of
>> the string or create a unique copy). As a user of the class, I do not have
>> to worry about the lifetime of the initial string. I can pass it around,
>> even to other threads... I just find this safer.
>>
>> Thanks,
>> Vincent
>>
>> On Saturday, September 28, 2013 2:09:08 PM UTC+2, Bjorn Reese wrote:
>>>
>>> On 09/28/2013 01:18 PM, Vincent Jacquet wrote:
>>>
>>> > Can someone point out use cases for this type?
>>>
>>> In one word: parsing.
>>>
>>> Most optimized parsers/lexers I am familiar with uses something
>>> reminiscent of string_view.
>>>
>>> For example, if you need to parse an XML document then you need to
>>> match start and end tags. With string_view you do not have to allocate
>>> a string containing the end tag just to compare it to the start tag.
>>>
>>> String_view is also useful if you need to skip over parts of the
>>> document without doing memory allocation.
>>>
>>>  --
>>
>> ---
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>  --
>
> ---
> 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-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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_1118_23446047.1380384562995
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree, this is why the type I briefly defined is not con=
st: it is mutable on the boundaries. I can truncate simply by adjusting its=
 length (not the one of the string is it referring to).<br><br><br>On Satur=
day, September 28, 2013 5:56:52 PM UTC+2, Billy O'Neal wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div style=3D"font-size:12pt;font-family:Cal=
ibri,sans-serif"><div>Not to mention, in a language with const, which decla=
res immutablity, there is little reason for a separate immutable type. I'd =
you want immutable semantics, just add const.</div><div><br></div><div>Sent=
 from a touchscreen. Please excuse the brevity and tpyos.</div><br><div>---=
-- Reply message -----<br>From: "Jeffrey Yasskin" &lt;<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"QiRWItLbezwJ">jyas...@google.=
com</a>&gt;<br>To: &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"QiRWItLbezwJ">std-pr...@isocpp.org</a>&gt;<br>Subject: [std-=
proposals] Use cases for string_view (N3762)?<br>Date: Sat, Sep 28, 2013 6:=
16 AM</div></div><br><p dir=3D"ltr">Since the standard doesn't currently ha=
ve an "immutable shared string" type, I decided not to invent one in order =
to get noncopying views on it.</p>
<div class=3D"gmail_quote">On Sep 28, 2013 8:00 AM, "Vincent Jacquet" &lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"QiRWItLbe=
zwJ">vjac...@flowgroup.fr</a>&gt; wrote:<br type=3D"attribution"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div dir=3D"ltr">I understand the handling part of a string as if it was a =
string, but "without doing memory allocation part". What I do not get is th=
e "non-owning" part. I cannot reason locally because of this. Whenever I wi=
ll use a string_view, I will have to think about the owner. For instance, I=
 cannot store a string_view in a class or a container unless I am sure that=
 the owner will be around longer than the instance this class or the contai=
ner.<br>
<br>If instead I define a type as "mutable range on an immutable shared str=
ing" (I call that a "stick", all puns intended and assumed), I can still pr=
ovide trimming, truncating and slicing without memory allocation but I can =
also&nbsp; guarante that the underlying string will not change ever (of cou=
rse, under construction, my class will have to either take ownership of the=
 string or create a unique copy). As a user of the class, I do not have to =
worry about the lifetime of the initial string. I can pass it around, even =
to other threads... I just find this safer.<br>
<br>Thanks,<br>Vincent<br><br>On Saturday, September 28, 2013 2:09:08 PM UT=
C+2, Bjorn Reese wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/28/201=
3 01:18 PM, Vincent Jacquet wrote:
<br>
<br>&gt; Can someone point out use cases for this type?
<br>
<br>In one word: parsing.
<br>
<br>Most optimized parsers/lexers I am familiar with uses something
<br>reminiscent of string_view.
<br>
<br>For example, if you need to parse an XML document then you need to
<br>match start and end tags. With string_view you do not have to allocate
<br>a string containing the end tag just to compare it to the start tag.
<br>
<br>String_view is also useful if you need to skip over parts of the
<br>document without doing memory allocation.
<br>
<br></blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
QiRWItLbezwJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"QiRWItLbezwJ">std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
QiRWItLbezwJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"QiRWItLbezwJ">std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1118_23446047.1380384562995--

.

------=_Part_13_1428934.1380384636006
Content-Type: text/plain; charset=ISO-8859-1

My objection is that once I have parsed, trimmed, tokenized a string, I
pass the result outside my function, so I could use it for a (potentially)
long while. The product of my parsing is meant to outlive my initial
string. I do not think this is the case for references.

Without use case, motivation, feedback from real use, I do not understand
why this type have to be "non-owning" in the first place, making it more
difficult to use. And without code sample, I do not know how I am supposed
to use it. If it is inspired from real use, could we have some feedback
then: were the bugs because of this design? How often? How long to fix them?


On Saturday, September 28, 2013 4:55:12 PM UTC+2, Nevin ":-)" Liber wrote:
>
> On 28 September 2013 09:37, Vincent Jacquet <vjac...@flowgroup.fr<javascript:>
> > wrote:
>
>> The string_view looks harmless.
>>
>
> Should I assume that you rarely pass anything by reference, because that
> suffers from the same issue?  Besides the usual dangers when using
> reference semantics, what is the objection?
>
> (Yeah, I preferred the name string_ref, but the committee as a whole
> preferred string_view.  Such is life.)
>
> IMO, it is needed.  "Strings" come from many different sources
> (std::string, std::vector<char>, C-literals, third party APIs, etc.), and
> it shows up in libraries with a variety of spellings.  I would much rather
> use string_view in my interfaces than hard-coding a specific string type.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (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/.

------=_Part_13_1428934.1380384636006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My objection is that  once I have parsed, trimmed, tokeniz=
ed a string, I pass the result outside my=20
function, so I could use it for a (potentially) long while. The product=20
of my parsing is meant to outlive my initial string. I do not think this is=
 the case for references.<br><br>Without use case, motivation, feedback fro=
m real use, I do not understand why this type have to be "non-owning" in th=
e first place, making it more difficult to use. And without code sample, I =
do not know how I am supposed to use it. If it is inspired from real use, c=
ould we have some feedback then: were the bugs because of this design? How =
often? How long to fix them?<br><br><br>On Saturday, September 28, 2013 4:5=
5:12 PM UTC+2, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr">On 28 September 2013 09:37, Vincent Jacquet <span=
 dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"38XTo8zRMJgJ">vjac...@flowgroup.fr</a>&gt;</span> wrote:<br><div><=
div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The string_view looks harml=
ess.</div></blockquote><div>&nbsp;</div><div>Should I assume that you rarel=
y pass anything by reference, because that suffers from the same issue? &nb=
sp;Besides the usual dangers when using reference semantics, what is the ob=
jection?</div>

<div><br></div><div>(Yeah, I preferred the name string_ref, but the committ=
ee as a whole preferred string_view. &nbsp;Such is life.)</div><div><br></d=
iv><div>IMO, it is needed. &nbsp;"Strings" come from many different sources=
 (std::string, std::vector&lt;char&gt;, C-literals, third party APIs, etc.)=
, and it shows up in libraries with a variety of spellings. &nbsp;I would m=
uch rather use string_view in my interfaces than hard-coding a specific str=
ing type.</div>

</div>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"38XTo8zRMJgJ">ne...@eviloverl=
ord.com</a><wbr>&gt;&nbsp; (847) 691-1404
</div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_13_1428934.1380384636006--

.

--089e0149c506a61b5e04e773de29
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Erm, no, it can't. To do so would violate guarantees in the standard about
run time or allocator behavior.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Sep 28, 2013 at 9:08 AM, Vincent Jacquet <vjacquet@flowgroup.fr>wro=
te:

> no, but it *could*. That's the point.
>
>
> On Saturday, September 28, 2013 5:55:17 PM UTC+2, Billy O'Neal wrote:
>
>> Perhaps, but the string does not actually know about its iterators. Just
>> because it returns them does not mean it keeps track of them.
>>
>> Sent from a touchscreen. Please excuse the brevity and tpyos.
>>
>> ----- Reply message -----
>> From: "Vincent Jacquet" <vjac...@flowgroup.fr>
>> To: <std-pr...@isocpp.org>
>> Subject: [std-proposals] Use cases for string_view (N3762)?
>> Date: Sat, Sep 28, 2013 7:37 AM
>>
>> The iterator is returned by the string. Unless I am mistaken, the
>> string_view is not. Therefore the string knows when it returns an iterat=
or.
>> It does not even know when a string_view references it. It does not feel
>> right. I mean, I'm okay with lending a pen. But if someone takes it with=
out
>> telling me, I'll call him a thief.
>>
>> Also the iterator is a concept we are taught about. I know I have to
>> manipulate it with care - mostly because it is so much like a pointer.
>> The string_view looks harmless. Once I am done with the parsing, let's
>> put the substring in a vector. Cool, there is not extra copy. So easy. A=
nd
>> potentially so wrong.
>>
>> It guess it proved to be fine to use this in applications where the
>> context of use is under control. But is it still ok in a standard librar=
y
>> anyone could use?
>>
>>
>> On Saturday, September 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=EBl Lamotte
>> wrote:
>>>
>>>
>>>
>>>
>>> On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <vjac...@flowgroup.fr>=
wrote:
>>>
>>>> I understand the handling part of a string as if it was a string, but
>>>> "without doing memory allocation part". What I do not get is the
>>>> "non-owning" part. I cannot reason locally because of this. Whenever I=
 will
>>>> use a string_view, I will have to think about the owner. For instance,=
 I
>>>> cannot store a string_view in a class or a container unless I am sure =
that
>>>> the owner will be around longer than the instance this class or the
>>>> container.
>>>>
>>>>
>>> You can store a string_view if you know it's refering to somehting that
>>> never changes, but yes it's not designed for this I guess.
>>> What you're asking would be for totally different use cases.
>>>
>>> If I remember correctly, Ranges concept don't imply ownership anyway.
>>>
>>> If instead I define a type as "mutable range on an immutable shared
>>>> string" (I call that a "stick", all puns intended and assumed), I can =
still
>>>> provide trimming, truncating and slicing without memory allocation but=
 I
>>>> can also  guarante that the underlying string will not change ever (of
>>>> course, under construction, my class will have to either take ownershi=
p of
>>>> the string or create a unique copy). As a user of the class, I do not =
have
>>>> to worry about the lifetime of the initial string. I can pass it aroun=
d,
>>>> even to other threads... I just find this safer.
>>>>
>>>>
>>> What you seem to suggest is that you like to have something like a
>>> string_view which is implicitely associated to, say a string or
>>> stringbuffer, and works with the same guarantees than iterators?
>>> I believe it's basically the same, but manipulating iterators or
>>> string_view when invalidated because the source have changed is undefin=
ed
>>> behaviour. I'm not sure if I'm 100% correct.
>>> Do you have a problem with iterators in general too?
>>>
>>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposal...@**isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>>
>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-**
>> proposals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>>
>  --
>
> ---
> 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/.
>

--=20

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

--089e0149c506a61b5e04e773de29
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Erm, no, it can&#39;t. To do so would violate guarantees i=
n the standard about run time or allocator behavior.<div class=3D"gmail_ext=
ra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div=
>
<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users=
/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/=
billy-oneal</a></div>


<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 9:08 AM, Vincent=
 Jacquet <span dir=3D"ltr">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" tar=
get=3D"_blank">vjacquet@flowgroup.fr</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bor=
der-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:sol=
id">


<div dir=3D"ltr">no, but it <i>could</i>. That&#39;s the point.<div><br><br=
>On Saturday, September 28, 2013 5:55:17 PM UTC+2, Billy O&#39;Neal wrote:<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bor=
der-left-style:solid">


<div style=3D"font-family:Calibri,sans-serif;font-size:12pt"><div><div>Perh=
aps, but the string does not actually know about its iterators. Just becaus=
e it returns them does not mean it keeps track of them.</div><div>
<br></div><div>Sent from a touchscreen. Please excuse the brevity and tpyos=
..</div><br></div><div><div>----- Reply message -----<br>From: &quot;Vincent=
 Jacquet&quot; &lt;<a>vjac...@flowgroup.fr</a>&gt;<br>To: &lt;<a>std-pr...@=
isocpp.org</a>&gt;<br>


Subject: [std-proposals] Use cases for string_view (N3762)?<br>Date: Sat, S=
ep 28, 2013 7:37 AM</div></div></div><div><br><div dir=3D"ltr">The iterator=
 is returned by the string. Unless I am mistaken, the string_view is not. T=
herefore the string knows when it returns an iterator. It does not even kno=
w when a string_view references it. It does not feel right. I mean, I&#39;m=
 okay with lending a pen. But if someone takes it without telling me, I&#39=
;ll call him a thief.<br>


<br>Also the iterator is a concept we are taught about. I know I have to ma=
nipulate it with care - mostly because it is so much like a pointer.<br>The=
 string_view looks harmless. Once I am done with the parsing, let&#39;s put=
 the substring in a vector. Cool, there is not extra copy. So easy. And pot=
entially so wrong.<br>


<br>It guess it proved to be fine to use this in applications where the con=
text of use is under control. But is it still ok in a standard library anyo=
ne could use?<br><br><br>On Saturday, September 28, 2013 3:17:42 PM UTC+2, =
Klaim - Jo=EBl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid">


<div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On Sat, Sep 28=
, 2013 at 3:00 PM, Vincent Jacquet <span dir=3D"ltr">&lt;<a>vjac...@flowgro=
up.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">I understand the handling part of a strin=
g as if it was a string, but &quot;without doing memory allocation part&quo=
t;. What I do not get is the &quot;non-owning&quot; part. I cannot reason l=
ocally because of this. Whenever I will use a string_view, I will have to t=
hink about the owner. For instance, I cannot store a string_view in a class=
 or a container unless I am sure that the owner will be around longer than =
the instance this class or the container.<br>



<br></div></blockquote><div><br></div><div>You can store a string_view if y=
ou know it&#39;s refering to somehting that never changes, but yes it&#39;s=
 not designed for this I guess.</div><div>What you&#39;re asking would be f=
or totally different use cases.</div>



<div><br></div><div>If I remember correctly, Ranges concept don&#39;t imply=
 ownership anyway.=A0</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid">



<div dir=3D"ltr">If instead I define a type as &quot;mutable range on an im=
mutable shared string&quot; (I call that a &quot;stick&quot;, all puns inte=
nded and assumed), I can still provide trimming, truncating and slicing wit=
hout memory allocation but I can also=A0 guarante that the underlying strin=
g will not change ever (of course, under construction, my class will have t=
o either take ownership of the string or create a unique copy). As a user o=
f the class, I do not have to worry about the lifetime of the initial strin=
g. I can pass it around, even to other threads... I just find this safer.<b=
r>



<br></div></blockquote><div><br></div><div>What you seem to suggest is that=
 you like to have something like a string_view which is implicitely associa=
ted to, say a string or stringbuffer, and works with the same guarantees th=
an iterators?<br>



I believe it&#39;s basically the same, but manipulating iterators or string=
_view when invalidated because the source have changed is undefined behavio=
ur. I&#39;m not sure if I&#39;m 100% correct.<br>Do you have a problem with=
 iterators in general too?</div>



<div>=A0=A0<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div><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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></blockquote></div><div><div>

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0149c506a61b5e04e773de29--

.

--089e01184768cd7e1c04e773e5bc
Content-Type: text/plain; charset=ISO-8859-1

Ok, well then don't use a string_view if you have no use for its semantics.
Plenty of people have plenty of uses for a type like this.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Sep 28, 2013 at 9:10 AM, Vincent Jacquet <vjacquet@flowgroup.fr>wrote:

> My objection is that once I have parsed, trimmed, tokenized a string, I
> pass the result outside my function, so I could use it for a (potentially)
> long while. The product of my parsing is meant to outlive my initial
> string. I do not think this is the case for references.
>
> Without use case, motivation, feedback from real use, I do not understand
> why this type have to be "non-owning" in the first place, making it more
> difficult to use. And without code sample, I do not know how I am supposed
> to use it. If it is inspired from real use, could we have some feedback
> then: were the bugs because of this design? How often? How long to fix them?
>
>
> On Saturday, September 28, 2013 4:55:12 PM UTC+2, Nevin ":-)" Liber wrote:
>>
>> On 28 September 2013 09:37, Vincent Jacquet <vjac...@flowgroup.fr> wrote:
>>
>>> The string_view looks harmless.
>>>
>>
>> Should I assume that you rarely pass anything by reference, because that
>> suffers from the same issue?  Besides the usual dangers when using
>> reference semantics, what is the objection?
>>
>> (Yeah, I preferred the name string_ref, but the committee as a whole
>> preferred string_view.  Such is life.)
>>
>> IMO, it is needed.  "Strings" come from many different sources
>> (std::string, std::vector<char>, C-literals, third party APIs, etc.), and
>> it shows up in libraries with a variety of spellings.  I would much rather
>> use string_view in my interfaces than hard-coding a specific string type.
>>  --
>>  Nevin ":-)" Liber  <mailto:ne...@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/.
>

--

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

--089e01184768cd7e1c04e773e5bc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div><div dir=3D"ltr"><div>Ok, =
well then don&#39;t use a string_view if you have no use for its semantics.=
 Plenty of people have plenty of uses for a type like this.</div><div>=A0</=
div><div>

Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" ta=
rget=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"htt=
p://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://sta=
ckoverflow.com/users/82320/billy-oneal</a></div>


<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 9:10 AM, Vincent=
 Jacquet <span dir=3D"ltr">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" tar=
get=3D"_blank">vjacquet@flowgroup.fr</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bor=
der-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:sol=
id">


<div dir=3D"ltr">My objection is that  once I have parsed, trimmed, tokeniz=
ed a string, I pass the result outside my=20
function, so I could use it for a (potentially) long while. The product=20
of my parsing is meant to outlive my initial string. I do not think this is=
 the case for references.<br><br>Without use case, motivation, feedback fro=
m real use, I do not understand why this type have to be &quot;non-owning&q=
uot; in the first place, making it more difficult to use. And without code =
sample, I do not know how I am supposed to use it. If it is inspired from r=
eal use, could we have some feedback then: were the bugs because of this de=
sign? How often? How long to fix them?<br>


<br><br>On Saturday, September 28, 2013 4:55:12 PM UTC+2, Nevin &quot;:-)&q=
uot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-w=
idth:1px;border-left-style:solid">


<div dir=3D"ltr">On 28 September 2013 09:37, Vincent Jacquet <span dir=3D"l=
tr">&lt;<a>vjac...@flowgroup.fr</a>&gt;</span> wrote:<br><div><div class=3D=
"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">The string_view looks harmless.</div></bl=
ockquote>


<div>=A0</div><div>Should I assume that you rarely pass anything by referen=
ce, because that suffers from the same issue? =A0Besides the usual dangers =
when using reference semantics, what is the objection?</div>

<div><br></div><div>(Yeah, I preferred the name string_ref, but the committ=
ee as a whole preferred string_view. =A0Such is life.)</div><div><br></div>=
<div>IMO, it is needed. =A0&quot;Strings&quot; come from many different sou=
rces (std::string, std::vector&lt;char&gt;, C-literals, third party APIs, e=
tc.), and it shows up in libraries with a variety of spellings. =A0I would =
much rather use string_view in my interfaces than hard-coding a specific st=
ring type.</div>


<span><font color=3D"#888888">

</font></span></div><span><font color=3D"#888888">-- <br>=A0Nevin &quot;:-)=
&quot; Liber=A0 &lt;mailto:<a>ne...@eviloverlord.com</a><u></u>&gt;=A0 <a h=
ref=3D"tel:%28847%29%20691-1404" target=3D"_blank" value=3D"+18476911404">(=
847) 691-1404</a>
</font></span></div></div>
</blockquote></div><div><div>

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e01184768cd7e1c04e773e5bc--

.

------=_Part_147_27171479.1380385286764
Content-Type: text/plain; charset=ISO-8859-1

Please, state them, this is the only thing I ask.

On Saturday, September 28, 2013 6:13:49 PM UTC+2, Billy O'Neal wrote:
>
> Ok, well then don't use a string_view if you have no use for its
> semantics. Plenty of people have plenty of uses for a type like this.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Sat, Sep 28, 2013 at 9:10 AM, Vincent Jacquet <vjac...@flowgroup.fr<javascript:>
> > wrote:
>
>> My objection is that once I have parsed, trimmed, tokenized a string, I
>> pass the result outside my function, so I could use it for a (potentially)
>> long while. The product of my parsing is meant to outlive my initial
>> string. I do not think this is the case for references.
>>
>> Without use case, motivation, feedback from real use, I do not understand
>> why this type have to be "non-owning" in the first place, making it more
>> difficult to use. And without code sample, I do not know how I am supposed
>> to use it. If it is inspired from real use, could we have some feedback
>> then: were the bugs because of this design? How often? How long to fix them?
>>
>>
>> On Saturday, September 28, 2013 4:55:12 PM UTC+2, Nevin ":-)" Liber wrote:
>>>
>>> On 28 September 2013 09:37, Vincent Jacquet <vjac...@flowgroup.fr>wrote:
>>>
>>>> The string_view looks harmless.
>>>>
>>>
>>> Should I assume that you rarely pass anything by reference, because that
>>> suffers from the same issue?  Besides the usual dangers when using
>>> reference semantics, what is the objection?
>>>
>>> (Yeah, I preferred the name string_ref, but the committee as a whole
>>> preferred string_view.  Such is life.)
>>>
>>> IMO, it is needed.  "Strings" come from many different sources
>>> (std::string, std::vector<char>, C-literals, third party APIs, etc.), and
>>> it shows up in libraries with a variety of spellings.  I would much rather
>>> use string_view in my interfaces than hard-coding a specific string type.
>>>  --
>>>  Nevin ":-)" Liber  <mailto:ne...@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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

---
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_147_27171479.1380385286764
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Please, state them, this is the only thing I ask. <br><br>=
On Saturday, September 28, 2013 6:13:49 PM UTC+2, Billy O'Neal wrote:<block=
quote 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"><div><div><div dir=
=3D"ltr"><div>Ok, well then don't use a string_view if you have no use for =
its semantics. Plenty of people have plenty of uses for a type like this.</=
div><div>&nbsp;</div><div>

Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" target=
=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http://=
stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stackov=
erflow.com/<wbr>users/82320/billy-oneal</a></div>


<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 9:10 AM, Vincent=
 Jacquet <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"HwdHkrBGmokJ">vjac...@flowgroup.fr</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid">


<div dir=3D"ltr">My objection is that  once I have parsed, trimmed, tokeniz=
ed a string, I pass the result outside my=20
function, so I could use it for a (potentially) long while. The product=20
of my parsing is meant to outlive my initial string. I do not think this is=
 the case for references.<br><br>Without use case, motivation, feedback fro=
m real use, I do not understand why this type have to be "non-owning" in th=
e first place, making it more difficult to use. And without code sample, I =
do not know how I am supposed to use it. If it is inspired from real use, c=
ould we have some feedback then: were the bugs because of this design? How =
often? How long to fix them?<br>


<br><br>On Saturday, September 28, 2013 4:55:12 PM UTC+2, Nevin ":-)" Liber=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;b=
order-left-style:solid">


<div dir=3D"ltr">On 28 September 2013 09:37, Vincent Jacquet <span dir=3D"l=
tr">&lt;<a>vjac...@flowgroup.fr</a>&gt;</span> wrote:<br><div><div class=3D=
"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">The string_view looks harmless.</div></bl=
ockquote>


<div>&nbsp;</div><div>Should I assume that you rarely pass anything by refe=
rence, because that suffers from the same issue? &nbsp;Besides the usual da=
ngers when using reference semantics, what is the objection?</div>

<div><br></div><div>(Yeah, I preferred the name string_ref, but the committ=
ee as a whole preferred string_view. &nbsp;Such is life.)</div><div><br></d=
iv><div>IMO, it is needed. &nbsp;"Strings" come from many different sources=
 (std::string, std::vector&lt;char&gt;, C-literals, third party APIs, etc.)=
, and it shows up in libraries with a variety of spellings. &nbsp;I would m=
uch rather use string_view in my interfaces than hard-coding a specific str=
ing type.</div>


<span><font color=3D"#888888">

</font></span></div><span><font color=3D"#888888">-- <br>&nbsp;Nevin ":-)" =
Liber&nbsp; &lt;mailto:<a>ne...@eviloverlord.com</a><u></u><wbr>&gt;&nbsp; =
<a value=3D"+18476911404">(847) 691-1404</a>
</font></span></div></div>
</blockquote></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
HwdHkrBGmokJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"HwdHkrBGmokJ">std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_147_27171479.1380385286764--

.

------=_Part_1099_20996347.1380385420280
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Are we talking about the same thing? In what way calling pop_back() in=20
class defined below would violate guarantees in the standard about run time=
=20
or allocator behavior?

template <class T, class Traits =3D char_traits<T>, class Alloc =3D=20
allocator<T>>
class basic_stick
{
    shared_ptr<const basic_string<T,Traits,Alloc>> ptr;
    size_t pos;
    size_t count;

public:
    basic_stick(basic_string<T,Traits,Alloc>&& s)
        : ptr(s), pos(0), count(ptr->size())
    {}
//...

    void pop_front() {
        ++pos;
    }
    void pop_back() {
        --count;
    }
};

On Saturday, September 28, 2013 6:11:48 PM UTC+2, Billy O'Neal wrote:
>
> Erm, no, it can't. To do so would violate guarantees in the standard abou=
t=20
> run time or allocator behavior.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Sat, Sep 28, 2013 at 9:08 AM, Vincent Jacquet <vjac...@flowgroup.fr<ja=
vascript:>
> > wrote:
>
>> no, but it *could*. That's the point.
>>
>>
>> On Saturday, September 28, 2013 5:55:17 PM UTC+2, Billy O'Neal wrote:
>>
>>> Perhaps, but the string does not actually know about its iterators. Jus=
t=20
>>> because it returns them does not mean it keeps track of them.
>>>
>>> Sent from a touchscreen. Please excuse the brevity and tpyos.
>>>
>>> ----- Reply message -----
>>> From: "Vincent Jacquet" <vjac...@flowgroup.fr>
>>> To: <std-pr...@isocpp.org>
>>> Subject: [std-proposals] Use cases for string_view (N3762)?
>>> Date: Sat, Sep 28, 2013 7:37 AM
>>>
>>> The iterator is returned by the string. Unless I am mistaken, the=20
>>> string_view is not. Therefore the string knows when it returns an itera=
tor.=20
>>> It does not even know when a string_view references it. It does not fee=
l=20
>>> right. I mean, I'm okay with lending a pen. But if someone takes it wit=
hout=20
>>> telling me, I'll call him a thief.
>>>
>>> Also the iterator is a concept we are taught about. I know I have to=20
>>> manipulate it with care - mostly because it is so much like a pointer.
>>> The string_view looks harmless. Once I am done with the parsing, let's=
=20
>>> put the substring in a vector. Cool, there is not extra copy. So easy. =
And=20
>>> potentially so wrong.
>>>
>>> It guess it proved to be fine to use this in applications where the=20
>>> context of use is under control. But is it still ok in a standard libra=
ry=20
>>> anyone could use?
>>>
>>>
>>> On Saturday, September 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=EBl Lamott=
e=20
>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <vjac...@flowgroup.fr=
>wrote:
>>>>
>>>>> I understand the handling part of a string as if it was a string, but=
=20
>>>>> "without doing memory allocation part". What I do not get is the=20
>>>>> "non-owning" part. I cannot reason locally because of this. Whenever =
I will=20
>>>>> use a string_view, I will have to think about the owner. For instance=
, I=20
>>>>> cannot store a string_view in a class or a container unless I am sure=
 that=20
>>>>> the owner will be around longer than the instance this class or the=
=20
>>>>> container.
>>>>>
>>>>>
>>>> You can store a string_view if you know it's refering to somehting tha=
t=20
>>>> never changes, but yes it's not designed for this I guess.
>>>> What you're asking would be for totally different use cases.
>>>>
>>>> If I remember correctly, Ranges concept don't imply ownership anyway.=
=20
>>>>
>>>> If instead I define a type as "mutable range on an immutable shared=20
>>>>> string" (I call that a "stick", all puns intended and assumed), I can=
 still=20
>>>>> provide trimming, truncating and slicing without memory allocation bu=
t I=20
>>>>> can also  guarante that the underlying string will not change ever (o=
f=20
>>>>> course, under construction, my class will have to either take ownersh=
ip of=20
>>>>> the string or create a unique copy). As a user of the class, I do not=
 have=20
>>>>> to worry about the lifetime of the initial string. I can pass it arou=
nd,=20
>>>>> even to other threads... I just find this safer.
>>>>>
>>>>>
>>>> What you seem to suggest is that you like to have something like a=20
>>>> string_view which is implicitely associated to, say a string or=20
>>>> stringbuffer, and works with the same guarantees than iterators?
>>>> I believe it's basically the same, but manipulating iterators or=20
>>>> string_view when invalidated because the source have changed is undefi=
ned=20
>>>> behaviour. I'm not sure if I'm 100% correct.
>>>> Do you have a problem with iterators in general too?
>>>>  =20
>>>>
>>>  --=20
>>> =20
>>> ---=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@**isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>>
>>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-*=
*
>>> proposals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>=
..
>>>
>>  --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

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

------=_Part_1099_20996347.1380385420280
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Are we talking about the same thing? In what way calling p=
op_back() in class defined below would violate guarantees in the standard a=
bout run time or allocator behavior?<br><br>template &lt;class T, class Tra=
its =3D char_traits&lt;T&gt;, class Alloc =3D allocator&lt;T&gt;&gt;<br>cla=
ss basic_stick<br>{<br>&nbsp;&nbsp;&nbsp; shared_ptr&lt;const basic_string&=
lt;T,Traits,Alloc&gt;&gt; ptr;<br>&nbsp;&nbsp;&nbsp; size_t pos;<br>&nbsp;&=
nbsp;&nbsp; size_t count;<br><br>public:<br>&nbsp;&nbsp;&nbsp; basic_stick(=
basic_string&lt;T,Traits,Alloc&gt;&amp;&amp; s)<br>&nbsp;&nbsp;&nbsp; &nbsp=
;&nbsp;&nbsp; : ptr(s), pos(0), count(ptr-&gt;size())<br>&nbsp;&nbsp;&nbsp;=
 {}<br>//...<br><br>&nbsp;&nbsp;&nbsp; void pop_front() {<br>&nbsp;&nbsp;&n=
bsp; &nbsp;&nbsp;&nbsp; ++pos;<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp=
; void pop_back() {<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; --count;<br>&n=
bsp;&nbsp;&nbsp; }<br>};<br><br>On Saturday, September 28, 2013 6:11:48 PM =
UTC+2, Billy O'Neal 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">Erm, no, it can't. To do so would violate guarantees in the st=
andard about run time or allocator behavior.<div><br clear=3D"all"><div><di=
v dir=3D"ltr"><div>Billy O'Neal</div><div>
<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users=
/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/<wbr>users/8=
2320/billy-oneal</a></div>


<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 9:08 AM, Vincent=
 Jacquet <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"1hbBnVI7C40J">vjac...@flowgroup.fr</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid">


<div dir=3D"ltr">no, but it <i>could</i>. That's the point.<div><br><br>On =
Saturday, September 28, 2013 5:55:17 PM UTC+2, Billy O'Neal wrote:</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-le=
ft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left=
-style:solid">


<div style=3D"font-family:Calibri,sans-serif;font-size:12pt"><div><div>Perh=
aps, but the string does not actually know about its iterators. Just becaus=
e it returns them does not mean it keeps track of them.</div><div>
<br></div><div>Sent from a touchscreen. Please excuse the brevity and tpyos=
..</div><br></div><div><div>----- Reply message -----<br>From: "Vincent Jacq=
uet" &lt;<a>vjac...@flowgroup.fr</a>&gt;<br>To: &lt;<a>std-pr...@isocpp.org=
</a>&gt;<br>


Subject: [std-proposals] Use cases for string_view (N3762)?<br>Date: Sat, S=
ep 28, 2013 7:37 AM</div></div></div><div><br><div dir=3D"ltr">The iterator=
 is returned by the string. Unless I am mistaken, the string_view is not. T=
herefore the string knows when it returns an iterator. It does not even kno=
w when a string_view references it. It does not feel right. I mean, I'm oka=
y with lending a pen. But if someone takes it without telling me, I'll call=
 him a thief.<br>


<br>Also the iterator is a concept we are taught about. I know I have to ma=
nipulate it with care - mostly because it is so much like a pointer.<br>The=
 string_view looks harmless. Once I am done with the parsing, let's put the=
 substring in a vector. Cool, there is not extra copy. So easy. And potenti=
ally so wrong.<br>


<br>It guess it proved to be fine to use this in applications where the con=
text of use is under control. But is it still ok in a standard library anyo=
ne could use?<br><br><br>On Saturday, September 28, 2013 3:17:42 PM UTC+2, =
Klaim - Jo=EBl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid">


<div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On Sat, Sep 28=
, 2013 at 3:00 PM, Vincent Jacquet <span dir=3D"ltr">&lt;<a>vjac...@flowgro=
up.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">I understand the handling part of a strin=
g as if it was a string, but "without doing memory allocation part". What I=
 do not get is the "non-owning" part. I cannot reason locally because of th=
is. Whenever I will use a string_view, I will have to think about the owner=
.. For instance, I cannot store a string_view in a class or a container unle=
ss I am sure that the owner will be around longer than the instance this cl=
ass or the container.<br>



<br></div></blockquote><div><br></div><div>You can store a string_view if y=
ou know it's refering to somehting that never changes, but yes it's not des=
igned for this I guess.</div><div>What you're asking would be for totally d=
ifferent use cases.</div>



<div><br></div><div>If I remember correctly, Ranges concept don't imply own=
ership anyway.&nbsp;</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(20=
4,204,204);border-left-width:1px;border-left-style:solid">



<div dir=3D"ltr">If instead I define a type as "mutable range on an immutab=
le shared string" (I call that a "stick", all puns intended and assumed), I=
 can still provide trimming, truncating and slicing without memory allocati=
on but I can also&nbsp; guarante that the underlying string will not change=
 ever (of course, under construction, my class will have to either take own=
ership of the string or create a unique copy). As a user of the class, I do=
 not have to worry about the lifetime of the initial string. I can pass it =
around, even to other threads... I just find this safer.<br>



<br></div></blockquote><div><br></div><div>What you seem to suggest is that=
 you like to have something like a string_view which is implicitely associa=
ted to, say a string or stringbuffer, and works with the same guarantees th=
an iterators?<br>



I believe it's basically the same, but manipulating iterators or string_vie=
w when invalidated because the source have changed is undefined behaviour. =
I'm not sure if I'm 100% correct.<br>Do you have a problem with iterators i=
n general too?</div>



<div>&nbsp;&nbsp;<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div><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/<u></u>iso<wbr=
>cpp.org/group/std-<u></u>proposals/</a>.<br>
</div></blockquote></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
1hbBnVI7C40J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"1hbBnVI7C40J">std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1099_20996347.1380385420280--

.

--001a11c2e81cb3ea5e04e774087f
Content-Type: text/plain; charset=ISO-8859-1

Anywhere where you're parsing.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Sep 28, 2013 at 9:21 AM, Vincent Jacquet <vjacquet@flowgroup.fr>wrote:

> Please, state them, this is the only thing I ask.
>
> On Saturday, September 28, 2013 6:13:49 PM UTC+2, Billy O'Neal wrote:
>
>> Ok, well then don't use a string_view if you have no use for its
>> semantics. Plenty of people have plenty of uses for a type like this.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/**users/82320/billy-oneal<http://stackoverflow.com/users/82320/billy-oneal>
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Sat, Sep 28, 2013 at 9:10 AM, Vincent Jacquet <vjac...@flowgroup.fr>wrote:
>>
>>>  My objection is that once I have parsed, trimmed, tokenized a string,
>>> I pass the result outside my function, so I could use it for a
>>> (potentially) long while. The product of my parsing is meant to outlive my
>>> initial string. I do not think this is the case for references.
>>>
>>> Without use case, motivation, feedback from real use, I do not
>>> understand why this type have to be "non-owning" in the first place, making
>>> it more difficult to use. And without code sample, I do not know how I am
>>> supposed to use it. If it is inspired from real use, could we have some
>>> feedback then: were the bugs because of this design? How often? How long to
>>> fix them?
>>>
>>>
>>> On Saturday, September 28, 2013 4:55:12 PM UTC+2, Nevin ":-)" Liber
>>> wrote:
>>>>
>>>> On 28 September 2013 09:37, Vincent Jacquet <vjac...@flowgroup.fr>wrote:
>>>>
>>>>> The string_view looks harmless.
>>>>>
>>>>
>>>> Should I assume that you rarely pass anything by reference, because
>>>> that suffers from the same issue?  Besides the usual dangers when using
>>>> reference semantics, what is the objection?
>>>>
>>>> (Yeah, I preferred the name string_ref, but the committee as a whole
>>>> preferred string_view.  Such is life.)
>>>>
>>>> IMO, it is needed.  "Strings" come from many different sources
>>>> (std::string, std::vector<char>, C-literals, third party APIs, etc.), and
>>>> it shows up in libraries with a variety of spellings.  I would much rather
>>>> use string_view in my interfaces than hard-coding a specific string type.
>>>>  --
>>>>  Nevin ":-)" Liber  <mailto:ne...@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-proposal...@**isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>>
>>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-**
>>> proposals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>>>
>>
>>  --
>
> ---
> 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/.
>

--

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

--001a11c2e81cb3ea5e04e774087f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Anywhere where you&#39;re parsing.</div><div class=3D"gmai=
l_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div=
><div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https=
://github.com/BillyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 9:21 AM, Vincent=
 Jacquet <span dir=3D"ltr">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" tar=
get=3D"_blank">vjacquet@flowgroup.fr</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div dir=3D"ltr">Please, state them, this is the only thing I ask. <br><div=
 class=3D"im"><br>On Saturday, September 28, 2013 6:13:49 PM UTC+2, Billy O=
&#39;Neal wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-l=
eft-width:1px;border-left-style:solid">

<div dir=3D"ltr"><div><div class=3D"im"><div><div dir=3D"ltr"><div>Ok, well=
 then don&#39;t use a string_view if you have no use for its semantics. Ple=
nty of people have plenty of uses for a type like this.</div><div>=A0</div>=
<div>



Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" ta=
rget=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"htt=
p://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://sta=
ckoverflow.com/<u></u>users/82320/billy-oneal</a></div>




<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div class=3D"gmail_quote"><div class=3D"im">On Sat, Sep 28, =
2013 at 9:10 AM, Vincent Jacquet <span dir=3D"ltr">&lt;<a>vjac...@flowgroup=
..fr</a>&gt;</span> wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">

<div class=3D"im">


<div dir=3D"ltr">My objection is that  once I have parsed, trimmed, tokeniz=
ed a string, I pass the result outside my=20
function, so I could use it for a (potentially) long while. The product=20
of my parsing is meant to outlive my initial string. I do not think this is=
 the case for references.<br><br>Without use case, motivation, feedback fro=
m real use, I do not understand why this type have to be &quot;non-owning&q=
uot; in the first place, making it more difficult to use. And without code =
sample, I do not know how I am supposed to use it. If it is inspired from r=
eal use, could we have some feedback then: were the bugs because of this de=
sign? How often? How long to fix them?<br>




<br><br>On Saturday, September 28, 2013 4:55:12 PM UTC+2, Nevin &quot;:-)&q=
uot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-w=
idth:1px;border-left-style:solid">




<div dir=3D"ltr">On 28 September 2013 09:37, Vincent Jacquet <span dir=3D"l=
tr">&lt;<a>vjac...@flowgroup.fr</a>&gt;</span> wrote:<br><div><div class=3D=
"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">The string_view looks harmless.</div></bl=
ockquote>




<div>=A0</div><div>Should I assume that you rarely pass anything by referen=
ce, because that suffers from the same issue? =A0Besides the usual dangers =
when using reference semantics, what is the objection?</div>

<div><br></div><div>(Yeah, I preferred the name string_ref, but the committ=
ee as a whole preferred string_view. =A0Such is life.)</div><div><br></div>=
<div>IMO, it is needed. =A0&quot;Strings&quot; come from many different sou=
rces (std::string, std::vector&lt;char&gt;, C-literals, third party APIs, e=
tc.), and it shows up in libraries with a variety of spellings. =A0I would =
much rather use string_view in my interfaces than hard-coding a specific st=
ring type.</div>




<span><font color=3D"#888888">

</font></span></div><span><font color=3D"#888888">-- <br>=A0Nevin &quot;:-)=
&quot; Liber=A0 &lt;mailto:<a>ne...@eviloverlord.com</a><u></u><u></u>&gt;=
=A0 <a value=3D"+18476911404">(847) 691-1404</a>
</font></span></div></div>
</blockquote></div></div><div><div><div class=3D"im">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div class=
=3D"im"><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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></div></blockquote></div><br></div></div>
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2e81cb3ea5e04e774087f--

.

--001a11c2c8eae8d38304e7742695
Content-Type: text/plain; charset=ISO-8859-1

On 28 September 2013 11:21, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

> Please, state them, this is the only thing I ask.
>

Besides the references in the paper, there is boost::iterator_range which
(at a high level) has the same semantics.
--
 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/.

--001a11c2c8eae8d38304e7742695
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 28 September 2013 11:21, Vincent Jacquet <span dir=3D"l=
tr">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet=
@flowgroup.fr</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Please, state them, this is=
 the only thing I ask. <br></div></blockquote><div><br></div><div>Besides t=
he references in the paper, there is boost::iterator_range which (at a high=
 level) has the same semantics.</div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2c8eae8d38304e7742695--

.

--001a11c33b02ee8c7804e7742ad2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I don't see how that's relevant; that isn't an iterator. begin and end are
required to be constant time; no operations on string are allowed to take
O(iterators); only O(number_of_characters).

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Sep 28, 2013 at 9:23 AM, Vincent Jacquet <vjacquet@flowgroup.fr>wro=
te:

> Are we talking about the same thing? In what way calling pop_back() in
> class defined below would violate guarantees in the standard about run ti=
me
> or allocator behavior?
>
> template <class T, class Traits =3D char_traits<T>, class Alloc =3D
> allocator<T>>
> class basic_stick
> {
>     shared_ptr<const basic_string<T,Traits,Alloc>> ptr;
>     size_t pos;
>     size_t count;
>
> public:
>     basic_stick(basic_string<T,Traits,Alloc>&& s)
>         : ptr(s), pos(0), count(ptr->size())
>     {}
> //...
>
>     void pop_front() {
>         ++pos;
>     }
>     void pop_back() {
>         --count;
>     }
> };
>
>
> On Saturday, September 28, 2013 6:11:48 PM UTC+2, Billy O'Neal wrote:
>
>> Erm, no, it can't. To do so would violate guarantees in the standard
>> about run time or allocator behavior.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/**users/82320/billy-oneal<http://stackoverflow.=
com/users/82320/billy-oneal>
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Sat, Sep 28, 2013 at 9:08 AM, Vincent Jacquet <vjac...@flowgroup.fr>w=
rote:
>>
>>> no, but it *could*. That's the point.
>>>
>>>
>>> On Saturday, September 28, 2013 5:55:17 PM UTC+2, Billy O'Neal wrote:
>>>
>>>> Perhaps, but the string does not actually know about its iterators.
>>>> Just because it returns them does not mean it keeps track of them.
>>>>
>>>> Sent from a touchscreen. Please excuse the brevity and tpyos.
>>>>
>>>> ----- Reply message -----
>>>> From: "Vincent Jacquet" <vjac...@flowgroup.fr>
>>>> To: <std-pr...@isocpp.org>
>>>> Subject: [std-proposals] Use cases for string_view (N3762)?
>>>> Date: Sat, Sep 28, 2013 7:37 AM
>>>>
>>>> The iterator is returned by the string. Unless I am mistaken, the
>>>> string_view is not. Therefore the string knows when it returns an iter=
ator.
>>>> It does not even know when a string_view references it. It does not fe=
el
>>>> right. I mean, I'm okay with lending a pen. But if someone takes it wi=
thout
>>>> telling me, I'll call him a thief.
>>>>
>>>> Also the iterator is a concept we are taught about. I know I have to
>>>> manipulate it with care - mostly because it is so much like a pointer.
>>>> The string_view looks harmless. Once I am done with the parsing, let's
>>>> put the substring in a vector. Cool, there is not extra copy. So easy.=
 And
>>>> potentially so wrong.
>>>>
>>>> It guess it proved to be fine to use this in applications where the
>>>> context of use is under control. But is it still ok in a standard libr=
ary
>>>> anyone could use?
>>>>
>>>>
>>>> On Saturday, September 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=EBl Lamot=
te
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <vjac...@flowgroup.f=
r
>>>>> > wrote:
>>>>>
>>>>>> I understand the handling part of a string as if it was a string, bu=
t
>>>>>> "without doing memory allocation part". What I do not get is the
>>>>>> "non-owning" part. I cannot reason locally because of this. Whenever=
 I will
>>>>>> use a string_view, I will have to think about the owner. For instanc=
e, I
>>>>>> cannot store a string_view in a class or a container unless I am sur=
e that
>>>>>> the owner will be around longer than the instance this class or the
>>>>>> container.
>>>>>>
>>>>>>
>>>>> You can store a string_view if you know it's refering to somehting
>>>>> that never changes, but yes it's not designed for this I guess.
>>>>> What you're asking would be for totally different use cases.
>>>>>
>>>>> If I remember correctly, Ranges concept don't imply ownership anyway.
>>>>>
>>>>> If instead I define a type as "mutable range on an immutable shared
>>>>>> string" (I call that a "stick", all puns intended and assumed), I ca=
n still
>>>>>> provide trimming, truncating and slicing without memory allocation b=
ut I
>>>>>> can also  guarante that the underlying string will not change ever (=
of
>>>>>> course, under construction, my class will have to either take owners=
hip of
>>>>>> the string or create a unique copy). As a user of the class, I do no=
t have
>>>>>> to worry about the lifetime of the initial string. I can pass it aro=
und,
>>>>>> even to other threads... I just find this safer.
>>>>>>
>>>>>>
>>>>> What you seem to suggest is that you like to have something like a
>>>>> string_view which is implicitely associated to, say a string or
>>>>> stringbuffer, and works with the same guarantees than iterators?
>>>>> I believe it's basically the same, but manipulating iterators or
>>>>> string_view when invalidated because the source have changed is undef=
ined
>>>>> behaviour. I'm not sure if I'm 100% correct.
>>>>> Do you have a problem with iterators in general too?
>>>>>
>>>>>
>>>>  --
>>>>
>>>> ---
>>>> 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-proposal...@**isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>
>>>> Visit this group at http://groups.google.com/a/**iso**
>>>> cpp.org/group/std-**proposals/<http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/>
>>>> .
>>>>
>>>  --
>>>
>>> ---
>>> 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-proposal...@**isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-*=
*
>>> proposals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>=
..
>>>
>>
>>  --
>
> ---
> 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/.
>

--=20

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

--001a11c33b02ee8c7804e7742ad2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t see how that&#39;s relevant; that isn&#39;t an=
 iterator. begin and end are required to be constant time; no operations=A0=
on string are allowed to take O(iterators); only O(number_of_characters).</=
div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 9:23 AM, Vincent=
 Jacquet <span dir=3D"ltr">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" tar=
get=3D"_blank">vjacquet@flowgroup.fr</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div dir=3D"ltr">Are we talking about the same thing? In what way calling p=
op_back() in class defined below would violate guarantees in the standard a=
bout run time or allocator behavior?<br><br>template &lt;class T, class Tra=
its =3D char_traits&lt;T&gt;, class Alloc =3D allocator&lt;T&gt;&gt;<br>

class basic_stick<br>{<br>=A0=A0=A0 shared_ptr&lt;const basic_string&lt;T,T=
raits,Alloc&gt;&gt; ptr;<br>=A0=A0=A0 size_t pos;<br>=A0=A0=A0 size_t count=
;<br><br>public:<br>=A0=A0=A0 basic_stick(basic_string&lt;T,Traits,Alloc&gt=
;&amp;&amp; s)<br>=A0=A0=A0 =A0=A0=A0 : ptr(s), pos(0), count(ptr-&gt;size(=
))<br>

=A0=A0=A0 {}<br>//...<br><br>=A0=A0=A0 void pop_front() {<br>=A0=A0=A0 =A0=
=A0=A0 ++pos;<br>=A0=A0=A0 }<br>=A0=A0=A0 void pop_back() {<br>=A0=A0=A0 =
=A0=A0=A0 --count;<br>=A0=A0=A0 }<br>};<div class=3D"im"><br><br>On Saturda=
y, September 28, 2013 6:11:48 PM UTC+2, Billy O&#39;Neal wrote:</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div class=3D"im">Erm, no, it can&#39;t. =
To do so would violate guarantees in the standard about run time or allocat=
or behavior.</div>

<div><div class=3D"im"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O=
&#39;Neal</div><div>
<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users=
/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/<u></u>users=
/82320/billy-oneal</a></div>




<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div><div class=3D"h5"><div class=3D"gmail_quote">On Sat, Sep=
 28, 2013 at 9:08 AM, Vincent Jacquet <span dir=3D"ltr">&lt;<a>vjac...@flow=
group.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">




<div dir=3D"ltr">no, but it <i>could</i>. That&#39;s the point.<div><br><br=
>On Saturday, September 28, 2013 5:55:17 PM UTC+2, Billy O&#39;Neal wrote:<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bor=
der-left-style:solid">




<div style=3D"font-family:Calibri,sans-serif;font-size:12pt"><div><div>Perh=
aps, but the string does not actually know about its iterators. Just becaus=
e it returns them does not mean it keeps track of them.</div><div>
<br></div><div>Sent from a touchscreen. Please excuse the brevity and tpyos=
..</div><br></div><div><div>----- Reply message -----<br>From: &quot;Vincent=
 Jacquet&quot; &lt;<a>vjac...@flowgroup.fr</a>&gt;<br>To: &lt;<a>std-pr...@=
isocpp.org</a>&gt;<br>




Subject: [std-proposals] Use cases for string_view (N3762)?<br>Date: Sat, S=
ep 28, 2013 7:37 AM</div></div></div><div><br><div dir=3D"ltr">The iterator=
 is returned by the string. Unless I am mistaken, the string_view is not. T=
herefore the string knows when it returns an iterator. It does not even kno=
w when a string_view references it. It does not feel right. I mean, I&#39;m=
 okay with lending a pen. But if someone takes it without telling me, I&#39=
;ll call him a thief.<br>




<br>Also the iterator is a concept we are taught about. I know I have to ma=
nipulate it with care - mostly because it is so much like a pointer.<br>The=
 string_view looks harmless. Once I am done with the parsing, let&#39;s put=
 the substring in a vector. Cool, there is not extra copy. So easy. And pot=
entially so wrong.<br>




<br>It guess it proved to be fine to use this in applications where the con=
text of use is under control. But is it still ok in a standard library anyo=
ne could use?<br><br><br>On Saturday, September 28, 2013 3:17:42 PM UTC+2, =
Klaim - Jo=EBl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid">




<div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On Sat, Sep 28=
, 2013 at 3:00 PM, Vincent Jacquet <span dir=3D"ltr">&lt;<a>vjac...@flowgro=
up.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">I understand the handling part of a strin=
g as if it was a string, but &quot;without doing memory allocation part&quo=
t;. What I do not get is the &quot;non-owning&quot; part. I cannot reason l=
ocally because of this. Whenever I will use a string_view, I will have to t=
hink about the owner. For instance, I cannot store a string_view in a class=
 or a container unless I am sure that the owner will be around longer than =
the instance this class or the container.<br>





<br></div></blockquote><div><br></div><div>You can store a string_view if y=
ou know it&#39;s refering to somehting that never changes, but yes it&#39;s=
 not designed for this I guess.</div><div>What you&#39;re asking would be f=
or totally different use cases.</div>





<div><br></div><div>If I remember correctly, Ranges concept don&#39;t imply=
 ownership anyway.=A0</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid">





<div dir=3D"ltr">If instead I define a type as &quot;mutable range on an im=
mutable shared string&quot; (I call that a &quot;stick&quot;, all puns inte=
nded and assumed), I can still provide trimming, truncating and slicing wit=
hout memory allocation but I can also=A0 guarante that the underlying strin=
g will not change ever (of course, under construction, my class will have t=
o either take ownership of the string or create a unique copy). As a user o=
f the class, I do not have to worry about the lifetime of the initial strin=
g. I can pass it around, even to other threads... I just find this safer.<b=
r>





<br></div></blockquote><div><br></div><div>What you seem to suggest is that=
 you like to have something like a string_view which is implicitely associa=
ted to, say a string or stringbuffer, and works with the same guarantees th=
an iterators?<br>





I believe it&#39;s basically the same, but manipulating iterators or string=
_view when invalidated because the source have changed is undefined behavio=
ur. I&#39;m not sure if I&#39;m 100% correct.<br>Do you have a problem with=
 iterators in general too?</div>





<div>=A0=A0<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div><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/<u></u>iso<u><=
/u>cpp.org/group/std-<u></u>proposals/</a>.<br>
</div></blockquote></div><div><div>

<p></p>

-- <br>
=A0<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>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c33b02ee8c7804e7742ad2--

.

------=_Part_1180_22790364.1380387851863
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My bad, I got lost in the replies and though you were talking about=20
something else.=20

On Saturday, September 28, 2013 6:33:09 PM UTC+2, Billy O'Neal wrote:
>
> I don't see how that's relevant; that isn't an iterator. begin and end ar=
e=20
> required to be constant time; no operations on string are allowed to take=
=20
> O(iterators); only O(number_of_characters).
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Sat, Sep 28, 2013 at 9:23 AM, Vincent Jacquet <vjac...@flowgroup.fr<ja=
vascript:>
> > wrote:
>
>> Are we talking about the same thing? In what way calling pop_back() in=
=20
>> class defined below would violate guarantees in the standard about run t=
ime=20
>> or allocator behavior?
>>
>> template <class T, class Traits =3D char_traits<T>, class Alloc =3D=20
>> allocator<T>>
>> class basic_stick
>> {
>>     shared_ptr<const basic_string<T,Traits,Alloc>> ptr;
>>     size_t pos;
>>     size_t count;
>>
>> public:
>>     basic_stick(basic_string<T,Traits,Alloc>&& s)
>>         : ptr(s), pos(0), count(ptr->size())
>>     {}
>> //...
>>
>>     void pop_front() {
>>         ++pos;
>>     }
>>     void pop_back() {
>>         --count;
>>     }
>> };
>>
>>
>> On Saturday, September 28, 2013 6:11:48 PM UTC+2, Billy O'Neal wrote:
>>
>>> Erm, no, it can't. To do so would violate guarantees in the standard=20
>>> about run time or allocator behavior.
>>>
>>> Billy O'Neal
>>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>>> http://stackoverflow.com/**users/82320/billy-oneal<http://stackoverflow=
..com/users/82320/billy-oneal>
>>> Malware Response Instructor - BleepingComputer.com
>>>
>>>
>>> On Sat, Sep 28, 2013 at 9:08 AM, Vincent Jacquet <vjac...@flowgroup.fr>=
wrote:
>>>
>>>> no, but it *could*. That's the point.
>>>>
>>>>
>>>> On Saturday, September 28, 2013 5:55:17 PM UTC+2, Billy O'Neal wrote:
>>>>
>>>>> Perhaps, but the string does not actually know about its iterators.=
=20
>>>>> Just because it returns them does not mean it keeps track of them.
>>>>>
>>>>> Sent from a touchscreen. Please excuse the brevity and tpyos.
>>>>>
>>>>> ----- Reply message -----
>>>>> From: "Vincent Jacquet" <vjac...@flowgroup.fr>
>>>>> To: <std-pr...@isocpp.org>
>>>>> Subject: [std-proposals] Use cases for string_view (N3762)?
>>>>> Date: Sat, Sep 28, 2013 7:37 AM
>>>>>
>>>>> The iterator is returned by the string. Unless I am mistaken, the=20
>>>>> string_view is not. Therefore the string knows when it returns an ite=
rator.=20
>>>>> It does not even know when a string_view references it. It does not f=
eel=20
>>>>> right. I mean, I'm okay with lending a pen. But if someone takes it w=
ithout=20
>>>>> telling me, I'll call him a thief.
>>>>>
>>>>> Also the iterator is a concept we are taught about. I know I have to=
=20
>>>>> manipulate it with care - mostly because it is so much like a pointer=
..
>>>>> The string_view looks harmless. Once I am done with the parsing, let'=
s=20
>>>>> put the substring in a vector. Cool, there is not extra copy. So easy=
.. And=20
>>>>> potentially so wrong.
>>>>>
>>>>> It guess it proved to be fine to use this in applications where the=
=20
>>>>> context of use is under control. But is it still ok in a standard lib=
rary=20
>>>>> anyone could use?
>>>>>
>>>>>
>>>>> On Saturday, September 28, 2013 3:17:42 PM UTC+2, Klaim - Jo=EBl Lamo=
tte=20
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Sep 28, 2013 at 3:00 PM, Vincent Jacquet <
>>>>>> vjac...@flowgroup.fr> wrote:
>>>>>>
>>>>>>> I understand the handling part of a string as if it was a string,=
=20
>>>>>>> but "without doing memory allocation part". What I do not get is th=
e=20
>>>>>>> "non-owning" part. I cannot reason locally because of this. Wheneve=
r I will=20
>>>>>>> use a string_view, I will have to think about the owner. For instan=
ce, I=20
>>>>>>> cannot store a string_view in a class or a container unless I am su=
re that=20
>>>>>>> the owner will be around longer than the instance this class or the=
=20
>>>>>>> container.
>>>>>>>
>>>>>>>
>>>>>> You can store a string_view if you know it's refering to somehting=
=20
>>>>>> that never changes, but yes it's not designed for this I guess.
>>>>>> What you're asking would be for totally different use cases.
>>>>>>
>>>>>> If I remember correctly, Ranges concept don't imply ownership anyway=
..=20
>>>>>>
>>>>>> If instead I define a type as "mutable range on an immutable shared=
=20
>>>>>>> string" (I call that a "stick", all puns intended and assumed), I c=
an still=20
>>>>>>> provide trimming, truncating and slicing without memory allocation =
but I=20
>>>>>>> can also  guarante that the underlying string will not change ever =
(of=20
>>>>>>> course, under construction, my class will have to either take owner=
ship of=20
>>>>>>> the string or create a unique copy). As a user of the class, I do n=
ot have=20
>>>>>>> to worry about the lifetime of the initial string. I can pass it ar=
ound,=20
>>>>>>> even to other threads... I just find this safer.
>>>>>>>
>>>>>>>
>>>>>> What you seem to suggest is that you like to have something like a=
=20
>>>>>> string_view which is implicitely associated to, say a string or=20
>>>>>> stringbuffer, and works with the same guarantees than iterators?
>>>>>> I believe it's basically the same, but manipulating iterators or=20
>>>>>> string_view when invalidated because the source have changed is unde=
fined=20
>>>>>> behaviour. I'm not sure if I'm 100% correct.
>>>>>> Do you have a problem with iterators in general too?
>>>>>>  =20
>>>>>>
>>>>>  --=20
>>>>> =20
>>>>> ---=20
>>>>> You received this message because you are subscribed to the Google=20
>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, sen=
d=20
>>>>> an email to std-proposal...@**isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>>
>>>>> Visit this group at http://groups.google.com/a/**iso**
>>>>> cpp.org/group/std-**proposals/<http://groups.google.com/a/isocpp.org/=
group/std-proposals/>
>>>>> .
>>>>>
>>>>  --=20
>>>> =20
>>>> ---=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@**isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-=
*
>>>> *proposals/<http://groups.google.com/a/isocpp.org/group/std-proposals/=
>
>>>> .
>>>>
>>>
>>>  --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

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

------=_Part_1180_22790364.1380387851863
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My bad, I got lost in the replies and though you were talk=
ing about something else. <br><br>On Saturday, September 28, 2013 6:33:09 P=
M UTC+2, Billy O'Neal wrote:<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">I don't see how that's relevant; that isn't an iterator. beg=
in and end are required to be constant time; no operations&nbsp;on string a=
re allowed to take O(iterators); only O(number_of_characters).</div>

<div><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a=
 href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://githu=
b.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/8=
2320/billy-oneal" target=3D"_blank">http://stackoverflow.com/<wbr>users/823=
20/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 9:23 AM, Vincent=
 Jacquet <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"IFxo7787Vu4J">vjac...@flowgroup.fr</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Are we talking about the same thing? In what way calling p=
op_back() in class defined below would violate guarantees in the standard a=
bout run time or allocator behavior?<br><br>template &lt;class T, class Tra=
its =3D char_traits&lt;T&gt;, class Alloc =3D allocator&lt;T&gt;&gt;<br>

class basic_stick<br>{<br>&nbsp;&nbsp;&nbsp; shared_ptr&lt;const basic_stri=
ng&lt;T,Traits,Alloc&gt;&gt; ptr;<br>&nbsp;&nbsp;&nbsp; size_t pos;<br>&nbs=
p;&nbsp;&nbsp; size_t count;<br><br>public:<br>&nbsp;&nbsp;&nbsp; basic_sti=
ck(basic_string&lt;T,<wbr>Traits,Alloc&gt;&amp;&amp; s)<br>&nbsp;&nbsp;&nbs=
p; &nbsp;&nbsp;&nbsp; : ptr(s), pos(0), count(ptr-&gt;size())<br>

&nbsp;&nbsp;&nbsp; {}<br>//...<br><br>&nbsp;&nbsp;&nbsp; void pop_front() {=
<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ++pos;<br>&nbsp;&nbsp;&nbsp; }<br=
>&nbsp;&nbsp;&nbsp; void pop_back() {<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nb=
sp; --count;<br>&nbsp;&nbsp;&nbsp; }<br>};<div><br><br>On Saturday, Septemb=
er 28, 2013 6:11:48 PM UTC+2, Billy O'Neal wrote:</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div>Erm, no, it can't. To do so would vi=
olate guarantees in the standard about run time or allocator behavior.</div=
>

<div><div><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><d=
iv>
<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users=
/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/<u></u>users=
<wbr>/82320/billy-oneal</a></div>




<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div><div><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at =
9:08 AM, Vincent Jacquet <span dir=3D"ltr">&lt;<a>vjac...@flowgroup.fr</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-le=
ft-width:1px;border-left-style:solid">




<div dir=3D"ltr">no, but it <i>could</i>. That's the point.<div><br><br>On =
Saturday, September 28, 2013 5:55:17 PM UTC+2, Billy O'Neal wrote:</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-le=
ft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left=
-style:solid">




<div style=3D"font-family:Calibri,sans-serif;font-size:12pt"><div><div>Perh=
aps, but the string does not actually know about its iterators. Just becaus=
e it returns them does not mean it keeps track of them.</div><div>
<br></div><div>Sent from a touchscreen. Please excuse the brevity and tpyos=
..</div><br></div><div><div>----- Reply message -----<br>From: "Vincent Jacq=
uet" &lt;<a>vjac...@flowgroup.fr</a>&gt;<br>To: &lt;<a>std-pr...@isocpp.org=
</a>&gt;<br>




Subject: [std-proposals] Use cases for string_view (N3762)?<br>Date: Sat, S=
ep 28, 2013 7:37 AM</div></div></div><div><br><div dir=3D"ltr">The iterator=
 is returned by the string. Unless I am mistaken, the string_view is not. T=
herefore the string knows when it returns an iterator. It does not even kno=
w when a string_view references it. It does not feel right. I mean, I'm oka=
y with lending a pen. But if someone takes it without telling me, I'll call=
 him a thief.<br>




<br>Also the iterator is a concept we are taught about. I know I have to ma=
nipulate it with care - mostly because it is so much like a pointer.<br>The=
 string_view looks harmless. Once I am done with the parsing, let's put the=
 substring in a vector. Cool, there is not extra copy. So easy. And potenti=
ally so wrong.<br>




<br>It guess it proved to be fine to use this in applications where the con=
text of use is under control. But is it still ok in a standard library anyo=
ne could use?<br><br><br>On Saturday, September 28, 2013 3:17:42 PM UTC+2, =
Klaim - Jo=EBl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid">




<div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On Sat, Sep 28=
, 2013 at 3:00 PM, Vincent Jacquet <span dir=3D"ltr">&lt;<a>vjac...@flowgro=
up.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">I understand the handling part of a strin=
g as if it was a string, but "without doing memory allocation part". What I=
 do not get is the "non-owning" part. I cannot reason locally because of th=
is. Whenever I will use a string_view, I will have to think about the owner=
.. For instance, I cannot store a string_view in a class or a container unle=
ss I am sure that the owner will be around longer than the instance this cl=
ass or the container.<br>





<br></div></blockquote><div><br></div><div>You can store a string_view if y=
ou know it's refering to somehting that never changes, but yes it's not des=
igned for this I guess.</div><div>What you're asking would be for totally d=
ifferent use cases.</div>





<div><br></div><div>If I remember correctly, Ranges concept don't imply own=
ership anyway.&nbsp;</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(20=
4,204,204);border-left-width:1px;border-left-style:solid">





<div dir=3D"ltr">If instead I define a type as "mutable range on an immutab=
le shared string" (I call that a "stick", all puns intended and assumed), I=
 can still provide trimming, truncating and slicing without memory allocati=
on but I can also&nbsp; guarante that the underlying string will not change=
 ever (of course, under construction, my class will have to either take own=
ership of the string or create a unique copy). As a user of the class, I do=
 not have to worry about the lifetime of the initial string. I can pass it =
around, even to other threads... I just find this safer.<br>





<br></div></blockquote><div><br></div><div>What you seem to suggest is that=
 you like to have something like a string_view which is implicitely associa=
ted to, say a string or stringbuffer, and works with the same guarantees th=
an iterators?<br>





I believe it's basically the same, but manipulating iterators or string_vie=
w when invalidated because the source have changed is undefined behaviour. =
I'm not sure if I'm 100% correct.<br>Do you have a problem with iterators i=
n general too?</div>





<div>&nbsp;&nbsp;<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div><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/<u></u>iso<u><=
/u><wbr>cpp.org/group/std-<u></u>proposals/</a>.<br>
</div></blockquote></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@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/<u></u>iso<wbr=
>cpp.org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
IFxo7787Vu4J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"IFxo7787Vu4J">std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1180_22790364.1380387851863--

.

--nextPart6888552.A0DpnjhvQ5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On s=E1bado, 28 de setembro de 2013 14:09:08, Bjorn Reese wrote:
> For example, if you need to parse an XML document then you need to
> match start and end tags. With string_view you do not have to allocat=
e
> a string containing the end tag just to compare it to the start tag.
>=20
> String_view is also useful if you need to skip over parts of the
> document without doing memory allocation.

I almost think that you had this in mind when you wrote the above:

string_view matches almost exactly the QStringRef class in Qt 4 and 5, =
which=20
was introduced exactly so that the new XML parsing class QXmlStreamRead=
er=20
would be able to return tags, attributes, text and others without causi=
ng=20
memory allocation.

See:
http://qt-project.org/doc/qt-5.1/qtcore/qstringref.html
http://qt-project.org/doc/qt-5.1/qtcore/qxmlstreamreader.html

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart6888552.A0DpnjhvQ5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBSRykEM/XwBW70U1gRAmNtAJwKrtiLTAuG8bTCC8G4paIHNE/g7wCfSHEW
82BFzWY573JAPA2GAnW3aXE=
=KNZm
-----END PGP SIGNATURE-----

--nextPart6888552.A0DpnjhvQ5--


.

------=_Part_1343_23994560.1380404638580
Content-Type: text/plain; charset=ISO-8859-1

Is there a reference implementation for std::string_view?

On Saturday, 28 September 2013 21:18:59 UTC+10, Vincent Jacquet wrote:
>
> I do not understand the intent of string_view and in what way it would be
> usefull for me.
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html>
>
> I understand that I get read access to a string without making an extra
> copy and the only mutable operation I can perform is to remove n chars at
> the front or the back.
>
> But the "non-owning" part gives me shivers. It implies that the instance
> of the view I get should not outlive the original object. If the intent of
> this type is to move references around, tracking the owner might get tricky.
>
> Then I have no guarantee whatsoever that the string I am viewing will not
> change. For any operation other than subsitution, the view might be
> invalidated.
>
> And, finally, a lot of potentially usefull methods are not available, such
> as trim (left, right, with a list of chars) or substring (before, after).
>
> Can someone point out use cases for this type?
> Thanks,
> Vincent
>

--

---
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_1343_23994560.1380404638580
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is there a reference implementation for std::string_view?<=
br><br>On Saturday, 28 September 2013 21:18:59 UTC+10, Vincent Jacquet  wro=
te:<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">I do not u=
nderstand the intent of string_view and in what way it would be usefull for=
 me.<br>&lt;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
013/n3762.html" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg=
21/docs/papers/2013/<wbr>n3762.html</a>&gt; <br><br>I understand that I get=
 read access to a string without making an extra copy and the only mutable =
operation I can perform is to remove n chars at the front or the back. <br>=
<br>But the "non-owning" part gives me shivers. It implies that the instanc=
e of the view I get should not outlive the original object. If the intent o=
f this type is to move references around, tracking the owner might get tric=
ky.<br><br>Then I have no guarantee whatsoever that the string I am viewing=
 will not change. For any operation other than subsitution, the view might =
be invalidated.<br><br>And, finally, a lot of potentially usefull methods a=
re not available, such as trim (left, right, with a list of chars) or subst=
ring (before, after).<br><br>Can someone point out use cases for this type?=
<br>Thanks,<br>Vincent<br></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1343_23994560.1380404638580--

.

--089e0158b5e8057d5604e7789470
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Sep 28, 2013 at 11:43 PM, Troy Heron <troy.heron@hixxy.org> wrote:

> Is there a reference implementation for std::string_view?


It's certainly not up to date but:
http://www.boost.org/doc/libs/1_54_0/libs/utility/doc/html/string_ref.html
As said in the first sentence it's based on a previous version of the
proposal.

--

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

--089e0158b5e8057d5604e7789470
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sat, Sep 28, 2013 at 11:43 PM, Troy Heron <span dir=3D"ltr">&lt;<a href=
=3D"mailto:troy.heron@hixxy.org" target=3D"_blank">troy.heron@hixxy.org</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Is there a reference implementation for std::string_view?<=
/blockquote>
</div><br>It&#39;s certainly not up to date but:=A0<a href=3D"http://www.bo=
ost.org/doc/libs/1_54_0/libs/utility/doc/html/string_ref.html">http://www.b=
oost.org/doc/libs/1_54_0/libs/utility/doc/html/string_ref.html</a><br>As sa=
id in the first sentence it&#39;s based on a previous version of the propos=
al.</div>
</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0158b5e8057d5604e7789470--

.

--001a11c37e302e3bef04e7789695
Content-Type: text/plain; charset=ISO-8859-1

On 29 September 2013 00:43, Troy Heron <troy.heron@hixxy.org> wrote:

> Is there a reference implementation for std::string_view?
>

Yes:
http://www.boost.org/doc/libs/1_54_0/libs/utility/doc/html/string_ref.html

--

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

--001a11c37e302e3bef04e7789695
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 29 September 2013 00:43, Troy Heron <span dir="ltr">&lt;<a href="mailto:troy.heron@hixxy.org" target="_blank">troy.heron@hixxy.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Is there a reference implementation for std::string_view?</div></blockquote><div><br>
</div><div>Yes:<br><a href="http://www.boost.org/doc/libs/1_54_0/libs/utility/doc/html/string_ref.html">http://www.boost.org/doc/libs/1_54_0/libs/utility/doc/html/string_ref.html</a><br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--001a11c37e302e3bef04e7789695--

.

------=_Part_1222_7434024.1380407232101
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you. The documentation clearly says what I have been trying to say (I=
=20
did the highlight) :

"For most users, there are no semantic benefits to using QStringRef instead=
=20
of QString <http://qt-project.org/doc/qt-5.1/qtcore/qstring.html> since QSt=
ringRef=20
requires attention to be paid to memory management issues, potentially=20
making code more complex to write and maintain.

*Warning:* A QStringRef is only valid as long as the referenced string=20
exists. If the original string is deleted, the string reference points to=
=20
an invalid memory location.

We suggest that you only use this class in stable code where profiling has=
=20
clearly identified that performance improvements can be made by replacing=
=20
standard string operations with the optimized substring handling provided=
=20
by this class."
When I read the documentation of the QXmlStreamReader, I guess that the=20
QStringRef returned by text() is valid only until the next read method. But=
=20
what about addData: does it invalidate the QStringRef? I do not know. I can=
=20
think of some implementations that might, and others that might not.


On Saturday, September 28, 2013 9:07:42 PM UTC+2, Thiago Macieira wrote:
>
> On s=E1bado, 28 de setembro de 2013 14:09:08, Bjorn Reese wrote:=20
> > For example, if you need to parse an XML document then you need to=20
> > match start and end tags. With string_view you do not have to allocate=
=20
> > a string containing the end tag just to compare it to the start tag.=20
> >=20
> > String_view is also useful if you need to skip over parts of the=20
> > document without doing memory allocation.=20
>
> I almost think that you had this in mind when you wrote the above:=20
>
> string_view matches almost exactly the QStringRef class in Qt 4 and 5,=20
> which=20
> was introduced exactly so that the new XML parsing class QXmlStreamReader=
=20
> would be able to return tags, attributes, text and others without causing=
=20
> memory allocation.=20
>
> See:=20
> http://qt-project.org/doc/qt-5.1/qtcore/qstringref.html=20
> http://qt-project.org/doc/qt-5.1/qtcore/qxmlstreamreader.html=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>

--=20

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

------=_Part_1222_7434024.1380407232101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you. The documentation clearly says what I have been=
 trying to say (I did the highlight) :<br><br>"For most users, there are no=
 semantic benefits to using QStringRef instead of <a href=3D"http://qt-proj=
ect.org/doc/qt-5.1/qtcore/qstring.html">QString</a>
 since <span style=3D"background-color: rgb(255, 229, 153);">QStringRef req=
uires attention to be paid to memory management=20
issues, potentially making code more complex to write and maintain</span>.<=
br><p><b>Warning:</b> A QStringRef is only valid as long as the referenced=
=20
string exists. If the original string is deleted, the string reference=20
points to an invalid memory location.</p>
<p>We suggest that you only use this class in stable code where=20
profiling has clearly identified that performance improvements can be=20
made by replacing standard string operations with the optimized=20
substring handling provided by this class."</p>When I read the documentatio=
n of the QXmlStreamReader, I guess that the QStringRef returned by text() i=
s valid only until the next read method. But what about addData: does it in=
validate the QStringRef? I do not know. I can think of some implementations=
 that might, and others that might not.<br><br><br>On Saturday, September 2=
8, 2013 9:07:42 PM UTC+2, Thiago Macieira wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">On s=E1bado, 28 de setembro de 2013 14:09:08, Bjorn Reese=
 wrote:
<br>&gt; For example, if you need to parse an XML document then you need to
<br>&gt; match start and end tags. With string_view you do not have to allo=
cate
<br>&gt; a string containing the end tag just to compare it to the start ta=
g.
<br>&gt;=20
<br>&gt; String_view is also useful if you need to skip over parts of the
<br>&gt; document without doing memory allocation.
<br>
<br>I almost think that you had this in mind when you wrote the above:
<br>
<br>string_view matches almost exactly the QStringRef class in Qt 4 and 5, =
which=20
<br>was introduced exactly so that the new XML parsing class QXmlStreamRead=
er=20
<br>would be able to return tags, attributes, text and others without causi=
ng=20
<br>memory allocation.
<br>
<br>See:
<br><a href=3D"http://qt-project.org/doc/qt-5.1/qtcore/qstringref.html" tar=
get=3D"_blank">http://qt-project.org/doc/qt-<wbr>5.1/qtcore/qstringref.html=
</a>
<br><a href=3D"http://qt-project.org/doc/qt-5.1/qtcore/qxmlstreamreader.htm=
l" target=3D"_blank">http://qt-project.org/doc/qt-<wbr>5.1/qtcore/qxmlstrea=
mreader.<wbr>html</a>
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1222_7434024.1380407232101--

.

------=_Part_1323_18606757.1380442603212
Content-Type: text/plain; charset=ISO-8859-1

Il giorno domenica 29 settembre 2013 00:27:12 UTC+2, Vincent Jacquet ha
scritto:
>
> "For most users, there are no semantic benefits to using QStringRef
> instead of QString <http://qt-project.org/doc/qt-5.1/qtcore/qstring.html>since QStringRef
> requires attention to be paid to memory management issues, potentially
> making code more complex to write and maintain.
>

I'll try to repeat my point, if you need lifetime guarantess you either use
a string or a shared_ptr<string> and construct string_views on the fly, for
example

class foobar
{
    ...
    shared_ptr<string> name_surname_;
     ...
    void foo()
    {
        assert( name_surname_ );

        string_view name = get_name_view( *name_surname_ );
        string_view surname = get_surname_view( *name_surname_ );

        if( name == "bar" )
        ... // no more copies, just views passed to non-mutable string
algorithms
    }
}

the above is not only optimal, but also more semantically correct ( I want
name to be a subrange, not a copy ) IMO. This
string_view ( and array_view ) is something I'm waiting for a long time ...
thank you to the proposer :)

When I read the documentation of the QXmlStreamReader, I guess that the
> QStringRef returned by text() is valid only until the next read method. But
> what about addData: does it invalidate the QStringRef? I do not know. I can
> think of some implementations that might, and others that might not.
>

where's the problem ? if the documentation doesn't give you that guarantee
you have no choice but constructing a real string <before> calling addData.

--

---
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_1323_18606757.1380442603212
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Il giorno domenica 29 settembre 2013 00:27:12 UTC+2, Vince=
nt Jacquet ha scritto:<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">"For most users, there are no semantic benefits to using QStringRe=
f instead of <a href=3D"http://qt-project.org/doc/qt-5.1/qtcore/qstring.htm=
l" target=3D"_blank">QString</a>
 since <span style=3D"background-color:rgb(255,229,153)">QStringRef require=
s attention to be paid to memory management=20
issues, potentially making code more complex to write and maintain</span>.<=
br></div></blockquote><div>&nbsp;<br>I'll try to repeat my point, if you ne=
ed lifetime guarantess you either use a string or a shared_ptr&lt;string&gt=
; and construct string_views on the fly, for example<br><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> foobar<br></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; </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; shared_ptr</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">&lt;string&gt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> name_surname_</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbs=
p;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">assert=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> name_surname_ </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; =
&nbsp; &nbsp; string_view name </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> get_name_view</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">name_surn=
ame_ </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &n=
bsp; &nbsp; &nbsp; string_view surname </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> get_surname_view</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"style=
d-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">name_surname_ </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">if</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> name </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"bar"<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nb=
sp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">// no more copies, jus=
t views passed to non-mutable string algorithms</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><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>the above is not =
only optimal, but also more semantically correct ( I want name to be a subr=
ange, not a copy ) IMO. This<br>string_view ( and array_view ) is something=
 I'm waiting for a long time ... thank you to the proposer :)<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">When I read t=
he documentation of the QXmlStreamReader, I guess that the QStringRef retur=
ned by text() is valid only until the next read method. But what about addD=
ata: does it invalidate the QStringRef? I do not know. I can think of some =
implementations that might, and others that might not.<br></div></blockquot=
e><div><br>where's the problem ? if the documentation doesn't give you that=
 guarantee you have no choice but constructing a real string &lt;before&gt;=
 calling addData. <br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1323_18606757.1380442603212--

.

------=_Part_1284_2372735.1380447872270
Content-Type: text/plain; charset=ISO-8859-1

Yes, having the hability to create a substring without copying is usefull.
I totally, completly agree with that.

What I do not agree, is the "non-owning part". This is unsafe *by design*
and I believe we could achieve the same kind of performance by having the
first instance taking ownership of the data and then sharing it among its
substrings. This is safe *by design*.

Don't you think that the non-owning part is kind of going backwards: we
have now unique_ptr/shared_ptr to manage lifetimes but, here, I will have
to manage the object lifetime myself ? The object I am referering to is
"string_view", as I may have one through function calls that is invalidated
latter because the original string has been destroyed. I know we have the
same "kind of problem" with iterators but iterators are conceptually
pointers and I have been thaught 20 years ago that I have to be cautious
around those. The string_view is conceptually a string, and I am used to
use them safely, without thinking of its lifetime.

If you put it in the standard, it is to be used and when you'll have
objects you did not implement returning string_view, I hope their
documentation will be very clear about its lifetime or then you'll be in
trouble. Not knowning *is* a problem.



On Sunday, September 29, 2013 10:16:43 AM UTC+2, MJanes wrote:
>
> Il giorno domenica 29 settembre 2013 00:27:12 UTC+2, Vincent Jacquet ha
> scritto:
>>
>> "For most users, there are no semantic benefits to using QStringRef
>> instead of QString <http://qt-project.org/doc/qt-5.1/qtcore/qstring.html>since QStringRef
>> requires attention to be paid to memory management issues, potentially
>> making code more complex to write and maintain.
>>
>
> I'll try to repeat my point, if you need lifetime guarantess you either
> use a string or a shared_ptr<string> and construct string_views on the fly,
> for example
>
> class foobar
> {
>     ...
>     shared_ptr<string> name_surname_;
>      ...
>     void foo()
>     {
>         assert( name_surname_ );
>
>         string_view name = get_name_view( *name_surname_ );
>         string_view surname = get_surname_view( *name_surname_ );
>
>         if( name == "bar" )
>         ... // no more copies, just views passed to non-mutable string
> algorithms
>     }
> }
>
> the above is not only optimal, but also more semantically correct ( I want
> name to be a subrange, not a copy ) IMO. This
> string_view ( and array_view ) is something I'm waiting for a long time
> ... thank you to the proposer :)
>
> When I read the documentation of the QXmlStreamReader, I guess that the
>> QStringRef returned by text() is valid only until the next read method. But
>> what about addData: does it invalidate the QStringRef? I do not know. I can
>> think of some implementations that might, and others that might not.
>>
>
> where's the problem ? if the documentation doesn't give you that guarantee
> you have no choice but constructing a real string <before> calling addData.
>

--

---
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_1284_2372735.1380447872270
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, having the hability to create a substring without cop=
ying is usefull. I totally, completly agree with that.<br><br>What I do not=
 agree, is the "non-owning part". This is unsafe *by design* and I believe =
we could achieve the same kind of performance by having the first instance =
taking ownership of the data and then sharing it among its substrings. This=
 is safe *by design*.<br><br>Don't you think that the non-owning part is ki=
nd of going backwards: we have now unique_ptr/shared_ptr to manage lifetime=
s but, here, I will have to manage the object lifetime myself ? The object =
I am referering to is "string_view", as I may have one through function cal=
ls that is invalidated latter because the original string has been destroye=
d. I know we have the same "kind of problem" with iterators but iterators a=
re conceptually pointers and I have been thaught 20 years ago that I have t=
o be cautious around those. The string_view is conceptually a string, and I=
 am used to use them safely, without thinking of its lifetime.<br><br>If yo=
u put it in the standard, it is to be used and when you'll have objects you=
 did not implement returning string_view, I hope their documentation will b=
e very clear about its lifetime or then you'll be in trouble. Not knowning =
*is* a problem. <br><br><br><br>On Sunday, September 29, 2013 10:16:43 AM U=
TC+2, MJanes 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">Il giorno domenica 29 settembre 2013 00:27:12 UTC+2, Vincent Jacquet =
ha scritto:<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">"For mo=
st users, there are no semantic benefits to using QStringRef instead of <a =
href=3D"http://qt-project.org/doc/qt-5.1/qtcore/qstring.html" target=3D"_bl=
ank">QString</a>
 since <span style=3D"background-color:rgb(255,229,153)">QStringRef require=
s attention to be paid to memory management=20
issues, potentially making code more complex to write and maintain</span>.<=
br></div></blockquote><div>&nbsp;<br>I'll try to repeat my point, if you ne=
ed lifetime guarantess you either use a string or a shared_ptr&lt;string&gt=
; and construct string_views on the fly, for example<br><br><div style=3D"b=
ackground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style=
:solid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"col=
or:#008">class</span><span style=3D"color:#000"> foobar<br></span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbsp; &nbsp; </sp=
an><span style=3D"color:#660">...</span><span style=3D"color:#000"><br>&nbs=
p; &nbsp; shared_ptr</span><span style=3D"color:#080">&lt;string&gt;</span>=
<span style=3D"color:#000"> name_surname_</span><span style=3D"color:#660">=
;</span><span style=3D"color:#000"><br>&nbsp; &nbsp; &nbsp;</span><span sty=
le=3D"color:#660">...</span><span style=3D"color:#000"><br>&nbsp; &nbsp; </=
span><span style=3D"color:#008">void</span><span style=3D"color:#000"> foo<=
/span><span style=3D"color:#660">()</span><span style=3D"color:#000"><br>&n=
bsp; &nbsp; </span><span style=3D"color:#660">{</span><span style=3D"color:=
#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color:#008">ass=
ert</span><span style=3D"color:#660">(</span><span style=3D"color:#000"> na=
me_surname_ </span><span style=3D"color:#660">);</span><span style=3D"color=
:#000"><br><br>&nbsp; &nbsp; &nbsp; &nbsp; string_view name </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> get_name_view</spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">*</span><span style=3D"color:#000">name_surname_ </=
span><span style=3D"color:#660">);</span><span style=3D"color:#000"><br>&nb=
sp; &nbsp; &nbsp; &nbsp; string_view surname </span><span style=3D"color:#6=
60">=3D</span><span style=3D"color:#000"> get_surname_view</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">*</span><span style=3D"color:#000">name_surname_ </span><span s=
tyle=3D"color:#660">);</span><span style=3D"color:#000"><br><br>&nbsp; &nbs=
p; &nbsp; &nbsp; </span><span style=3D"color:#008">if</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000"> name </span><span style=3D"=
color:#660">=3D=3D</span><span style=3D"color:#000"> </span><span style=3D"=
color:#080">"bar"</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">)</span><span style=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; &nbs=
p; </span><span style=3D"color:#660">...</span><span style=3D"color:#000"> =
</span><span style=3D"color:#800">// no more copies, just views passed to n=
on-mutable string algorithms</span><span style=3D"color:#000"><br>&nbsp; &n=
bsp; </span><span style=3D"color:#660">}</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br=
></span></div></code></div><br>the above is not only optimal, but also more=
 semantically correct ( I want name to be a subrange, not a copy ) IMO. Thi=
s<br>string_view ( and array_view ) is something I'm waiting for a long tim=
e ... thank you to the proposer :)<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">When I read the documentation of the QXmlStre=
amReader, I guess that the QStringRef returned by text() is valid only unti=
l the next read method. But what about addData: does it invalidate the QStr=
ingRef? I do not know. I can think of some implementations that might, and =
others that might not.<br></div></blockquote><div><br>where's the problem ?=
 if the documentation doesn't give you that guarantee you have no choice bu=
t constructing a real string &lt;before&gt; calling addData. <br></div></di=
v></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1284_2372735.1380447872270--

.

------=_Part_1356_3684788.1380453413991
Content-Type: text/plain; charset=ISO-8859-1

Il giorno domenica 29 settembre 2013 11:44:32 UTC+2, Vincent Jacquet ha
scritto:

> The string_view is conceptually a string, and I am used to use them
> safely, without thinking of its lifetime.
>

that's the problem, a string_view is not a string. The idea of non-owning
views is not new and, I'd say, it has become idiomatic in the same way
references and iterators are. A view is just a "decorated" reference, and a
string view is just a replacement for a "string const&", without the
obvious performance drawbacks of the latter.

Don't you think that the non-owning part is kind of going backwards: we
> have now unique_ptr/shared_ptr to manage lifetimes but, here, I will have
> to manage the object lifetime myself ?
>

it's just separation of concerns, isn't it ? why do we have to pay for
ownsership semantics ( which one ? ) for something whose only purpose is to
be a non mutable adaptor exposing a string interface around a contiguous
array of char's ?

I believe we could achieve the same kind of performance by having the first
> instance taking ownership of the data and then sharing it among its
> substrings


I don't think so, a string_view should be just a pair of pointers and
constructing it from a string should be just some simple pointer copy.
Adding a shared pointer would double the size ( + the reference counter
allocation ) and add nearly-always-useless reference counter updates.


--

---
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_1356_3684788.1380453413991
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Il giorno domenica 29 settembre 2013 11:44:32 UTC+2, Vince=
nt Jacquet ha scritto:<br><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">The string_view is conceptually a string, and I am used to use=
 them safely, without thinking of its lifetime.<br></div></blockquote><br>t=
hat's the problem, a string_view is not a string. The idea of=20
non-owning views is not new and, I'd say, it has become idiomatic in the
 same way references and iterators are. A view is just a "decorated"=20
reference, and a string view is just a replacement for a "string=20
const&amp;", without the obvious performance drawbacks of the latter.<br><b=
r><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">Don't you t=
hink that the non-owning part is kind of going backwards: we have now uniqu=
e_ptr/shared_ptr to manage lifetimes but, here, I will have to manage the o=
bject lifetime myself ? </div></blockquote><div><br>it's just separation of=
 concerns, isn't it ? why do we have to pay for=20
ownsership semantics ( which one ? ) for something whose only purpose is
 to be a non mutable adaptor exposing a string interface around a=20
contiguous array of char's ?<br><br><blockquote style=3D"margin: 0px 0px 0p=
x 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" cla=
ss=3D"gmail_quote">I believe we could achieve the same kind of performance =
by having the=20
first instance taking ownership of the data and then sharing it among=20
its substrings</blockquote><br>I don't think so, a string_view=20
should be just a pair of pointers and constructing it from a string=20
should be just some simple pointer copy. Adding a shared pointer would=20
double the size ( + the reference counter allocation ) and add=20
nearly-always-useless reference counter updates.</div><div>&nbsp;</div></di=
v>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1356_3684788.1380453413991--

.

------=_Part_1550_9817474.1380473542056
Content-Type: text/plain; charset=ISO-8859-1


On Sunday, September 29, 2013 1:16:53 PM UTC+2, MJanes wrote:
>
> Il giorno domenica 29 settembre 2013 11:44:32 UTC+2, Vincent Jacquet ha
> scritto:
>
>> The string_view is conceptually a string, and I am used to use them
>> safely, without thinking of its lifetime.
>>
>
> that's the problem, a string_view is not a string. The idea of non-owning
> views is not new and, I'd say, it has become idiomatic in the same way
> references and iterators are. A view is just a "decorated" reference, and a
> string view is just a replacement for a "string const&", without the
> obvious performance drawbacks of the latter.
>

 Isn't the view about creating substrings cheaply. If you don't need that,
then isn't string const& just fine?


> Don't you think that the non-owning part is kind of going backwards: we
>> have now unique_ptr/shared_ptr to manage lifetimes but, here, I will have
>> to manage the object lifetime myself ?
>>
>
> it's just separation of concerns, isn't it ? why do we have to pay for
> ownsership semantics ( which one ? ) for something whose only purpose is to
> be a non mutable adaptor exposing a string interface around a contiguous
> array of char's ?
>

Isn't it "a mutable adaptor (remove_prefix/remove_suffix) exposing a
readonly string interface around a contiguous of array char's, which is
expected to be alived and not changed as long as the adaptor, it is not
even aware of, lives" ?
You cannot make a *safe* adaptor exposing a string interface around a
contiguous array of char's unless you own this array or shares it with
objects that respects the same contract of not modifying it or not
destroying it as long as it is in use. With this class, making your program
safe is all on you. You cannot expect help from the class nor the compiler.
I am sure you are smart enough to do so. Can you vouch for every programmer
you know?


>
> I believe we could achieve the same kind of performance by having the
>> first instance taking ownership of the data and then sharing it among its
>> substrings
>
>
> I don't think so, a string_view should be just a pair of pointers and
> constructing it from a string should be just some simple pointer copy.
> Adding a shared pointer would double the size ( + the reference counter
> allocation ) and add nearly-always-useless reference counter updates.
>
>
Yes there is a little performance penalty, but it is not as bad as having
to copy the whole string over and over again. And there might still be a
way to define ownership policies.

We are not talking about implementing a little utility class in your
program, where you can nicely encapsulate all those memory issues in a
class. We are talking about adding a class to the standard library for
which you have no idea how people will use and misuse it. And it is just so
tempting to simply move this class around because it is cheap...

Anyway, in the long run, I find this class definition more dangerous than
useful. I wanted to say it. I did and I hope I am wrong. So can we agree to
disagree?

--

---
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_1550_9817474.1380473542056
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Sunday, September 29, 2013 1:16:53 PM UTC+2, MJanes=
 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">Il gio=
rno domenica 29 settembre 2013 11:44:32 UTC+2, Vincent Jacquet ha scritto:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The string_view=
 is conceptually a string, and I am used to use them safely, without thinki=
ng of its lifetime.<br></div></blockquote><br>that's the problem, a string_=
view is not a string. The idea of=20
non-owning views is not new and, I'd say, it has become idiomatic in the
 same way references and iterators are. A view is just a "decorated"=20
reference, and a string view is just a replacement for a "string=20
const&amp;", without the obvious performance drawbacks of the latter.<br> <=
/div></blockquote><div dir=3D"ltr"><br>&nbsp;Isn't the view about creating =
substrings cheaply. If you don't need that, then isn't string const&amp; ju=
st fine?<br></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"><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">Don't you think that the non-owning part is kind of going backwards: w=
e have now unique_ptr/shared_ptr to manage lifetimes but, here, I will have=
 to manage the object lifetime myself ? </div></blockquote><div><br>it's ju=
st separation of concerns, isn't it ? why do we have to pay for=20
ownsership semantics ( which one ? ) for something whose only purpose is
 to be a non mutable adaptor exposing a string interface around a=20
contiguous array of char's ?<br></div></div></blockquote><div><br>Isn't it =
"a mutable adaptor (remove_prefix/remove_suffix) exposing a readonly string=
 interface around a contiguous of array char's, which is expected to be ali=
ved and not changed as long as the adaptor, it is not even aware of, lives"=
 ?<br>You cannot make a *safe* adaptor exposing a string interface around a=
 contiguous array of char's unless you own this array or shares it with obj=
ects that respects the same contract of not modifying it or not destroying =
it as long as it is in use. With this class, making your program safe is al=
l on you. You cannot expect help from the class nor the compiler. I am sure=
 you are smart enough to do so. Can you vouch for every programmer you know=
?<br>&nbsp;</div><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><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">I believe we=
 could achieve the same kind of performance by having the=20
first instance taking ownership of the data and then sharing it among=20
its substrings</blockquote><br>I don't think so, a string_view=20
should be just a pair of pointers and constructing it from a string=20
should be just some simple pointer copy. Adding a shared pointer would=20
double the size ( + the reference counter allocation ) and add=20
nearly-always-useless reference counter updates.</div><div>&nbsp;</div></di=
v></blockquote><div>Yes there is a little performance penalty, but it is no=
t as bad as having to copy the whole string over and over again. And there =
might still be a way to define ownership policies. <br><br>We are not talki=
ng about implementing a little utility class in your program, where you can=
 nicely encapsulate all those memory issues in a class. We are talking abou=
t adding a class to the standard library for which you have no idea how peo=
ple will use and misuse it. And it is just so tempting to simply move this =
class around because it is cheap... <br><br>Anyway, in the long run, I find=
 this class definition more dangerous than useful. I wanted to say it. I di=
d and I hope I am wrong. So can we agree to disagree?<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1550_9817474.1380473542056--

.

--001a11c227e88afda804e788eb43
Content-Type: text/plain; charset=ISO-8859-1

On 29 September 2013 19:52, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

>
> We are not talking about implementing a little utility class in your
> program, where you can nicely encapsulate all those memory issues in a
> class. We are talking about adding a class to the standard library for
> which you have no idea how people will use and misuse it. And it is just so
> tempting to simply move this class around because it is cheap...
>
>
Well, we actually think we do know how people will use and misuse it, since
equivalent
types have actual practical use experience.

--

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

--001a11c227e88afda804e788eb43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 September 2013 19:52, Vincent Jacquet <span dir=3D"ltr">&lt;<=
a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flowgrou=
p.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>We are not talking=
 about implementing a little utility class in your program, where you can n=
icely encapsulate all those memory issues in a class. We are talking about =
adding a class to the standard library for which you have no idea how peopl=
e will use and misuse it. And it is just so tempting to simply move this cl=
ass around because it is cheap... <br>
<br></div></div></blockquote><div><br></div><div>Well, we actually think we=
 do know how people will use and misuse it, since equivalent<br>types have =
actual practical use experience. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c227e88afda804e788eb43--

.

Le 28/09/2013 14:23, Vincent Jacquet a =C3=A9crit :
> Thanks but, basically, I find the "others did it, so we should do it"=20
> argument kind of weak. I mean as it is inspired by real use, can we=20
> have some of them as example and some figures? i.e. under these=20
> conditions, the use of "string_view" in place of "string" resulted in=20
> a performance improvement of x%, and a decrease of memory consumption=20
> of y%.

I can't give you specific figures, but on one of the source code I=20
worked with (a parser), I divided the execution time by 2 by switching=20
from string to a string_view like class. The code is slightly more=20
complex, because of switching from value semantic to reference semantic,=20
but the result was worth it.

---
Lo=C4=8Fc

--=20

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

.

------=_Part_7_11412879.1380476639495
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you.=20

On Sunday, September 29, 2013 7:22:54 PM UTC+2, Lo=EFc Joly wrote:
>
> Le 28/09/2013 14:23, Vincent Jacquet a =EF=BF=BDcrit :=20
> > Thanks but, basically, I find the "others did it, so we should do it"=
=20
> > argument kind of weak. I mean as it is inspired by real use, can we=20
> > have some of them as example and some figures? i.e. under these=20
> > conditions, the use of "string_view" in place of "string" resulted in=
=20
> > a performance improvement of x%, and a decrease of memory consumption=
=20
> > of y%.=20
>
> I can't give you specific figures, but on one of the source code I=20
> worked with (a parser), I divided the execution time by 2 by switching=20
> from string to a string_view like class. The code is slightly more=20
> complex, because of switching from value semantic to reference semantic,=
=20
> but the result was worth it.=20
>
> ---=20
> Lo=EF=BF=BDc=20
>
>

--=20

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

------=_Part_7_11412879.1380476639495
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you. <br><br>On Sunday, September 29, 2013 7:22:54 P=
M UTC+2, Lo=EFc Joly wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le =
28/09/2013 14:23, Vincent Jacquet a =EF=BF=BDcrit :
<br>&gt; Thanks but, basically, I find the "others did it, so we should do =
it"=20
<br>&gt; argument kind of weak. I mean as it is inspired by real use, can w=
e=20
<br>&gt; have some of them as example and some figures? i.e. under these=20
<br>&gt; conditions, the use of "string_view" in place of "string" resulted=
 in=20
<br>&gt; a performance improvement of x%, and a decrease of memory consumpt=
ion=20
<br>&gt; of y%.
<br>
<br>I can't give you specific figures, but on one of the source code I=20
<br>worked with (a parser), I divided the execution time by 2 by switching=
=20
<br>from string to a string_view like class. The code is slightly more=20
<br>complex, because of switching from value semantic to reference semantic=
,=20
<br>but the result was worth it.
<br>
<br>---
<br>Lo=EF=BF=BDc
<br>
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_7_11412879.1380476639495--

.

------=_Part_3_25065274.1380476681692
Content-Type: text/plain; charset=ISO-8859-1

Excellent. Would you mind sharing some of your insights?

On Sunday, September 29, 2013 7:19:20 PM UTC+2, Ville Voutilainen wrote:
>
>
>
>
> On 29 September 2013 19:52, Vincent Jacquet <vjac...@flowgroup.fr<javascript:>
> > wrote:
>
>>
>> We are not talking about implementing a little utility class in your
>> program, where you can nicely encapsulate all those memory issues in a
>> class. We are talking about adding a class to the standard library for
>> which you have no idea how people will use and misuse it. And it is just so
>> tempting to simply move this class around because it is cheap...
>>
>>
> Well, we actually think we do know how people will use and misuse it,
> since equivalent
> types have actual practical use experience.
>
>

--

---
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_3_25065274.1380476681692
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Excellent. Would you mind sharing some of your insights?<b=
r><br>On Sunday, September 29, 2013 7:19:20 PM UTC+2, Ville Voutilainen wro=
te:<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"><br><div><=
br><br><div class=3D"gmail_quote">On 29 September 2013 19:52, Vincent Jacqu=
et <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"hXIjmoq3c7gJ">vjac...@flowgroup.fr</a>&gt;</span> wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>We are not talking=
 about implementing a little utility class in your program, where you can n=
icely encapsulate all those memory issues in a class. We are talking about =
adding a class to the standard library for which you have no idea how peopl=
e will use and misuse it. And it is just so tempting to simply move this cl=
ass around because it is cheap... <br>
<br></div></div></blockquote><div><br></div><div>Well, we actually think we=
 do know how people will use and misuse it, since equivalent<br>types have =
actual practical use experience. <br></div></div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3_25065274.1380476681692--

.

--001a1134c928286ec604e7895ec3
Content-Type: text/plain; charset=ISO-8859-1

On 29 September 2013 20:44, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

> Excellent. Would you mind sharing some of your insights?
>

Did you read the paper? The latest one is
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3762.html

Having a reference-to-a-substr is more convenient and generic than its
work-arounds
(char* + size, iterator pairs), and more efficient than copying strings or
their substrings
around. That's the gist of it. It's less safe than copying strings around,
but arguably
safer (mostly due to its convenience) than char* + size or iterator pairs.
Chromium,
LLVM, Bloomberg and Qt have equivalent types for various combinations of the
aforementioned reasons. That's not a "let's do it because others do it",
it's existing
practice, and it's usually beneficial to standardize existing practice.


>
> On Sunday, September 29, 2013 7:19:20 PM UTC+2, Ville Voutilainen wrote:
>
>>
>>
>>
>> On 29 September 2013 19:52, Vincent Jacquet <vjac...@flowgroup.fr> wrote:
>>
>>>
>>> We are not talking about implementing a little utility class in your
>>> program, where you can nicely encapsulate all those memory issues in a
>>> class. We are talking about adding a class to the standard library for
>>> which you have no idea how people will use and misuse it. And it is just so
>>> tempting to simply move this class around because it is cheap...
>>>
>>>
>> Well, we actually think we do know how people will use and misuse it,
>> since equivalent
>> types have actual practical use experience.
>>
>>  --
>
> ---
> 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/.
>

--

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

--001a1134c928286ec604e7895ec3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 September 2013 20:44, Vincent Jacquet <span dir=3D"ltr">&lt;<=
a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flowgrou=
p.fr</a>&gt;</span> wrote:<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 dir=3D"ltr">Excellen=
t. Would you mind sharing some of your insights?<br></div></blockquote><div=
><br>
</div><div>Did you read the paper? The latest one is<br><a href=3D"http://o=
pen-std.org/JTC1/SC22/WG21/docs/papers/2013/n3762.html">http://open-std.org=
/JTC1/SC22/WG21/docs/papers/2013/n3762.html</a><br><br></div><div>Having a =
reference-to-a-substr is more convenient and generic than its work-arounds<=
br>
</div><div>(char* + size, iterator pairs), and more efficient than copying =
strings or their substrings<br>around. That&#39;s the gist of it. It&#39;s =
less safe than copying strings around, but arguably<br>safer (mostly due to=
 its convenience) than char* + size or iterator pairs. Chromium,<br>
</div><div>LLVM, Bloomberg and Qt have equivalent types for various combina=
tions of the<br>aforementioned reasons. That&#39;s not a &quot;let&#39;s do=
 it because others do it&quot;, it&#39;s existing<br>practice, and it&#39;s=
 usually beneficial to standardize existing practice.<br>
</div><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><br>On Sunday, September 29, 2013 7:19:20 PM UTC+2, Ville V=
outilainen wrote:<div>
<div class=3D"h5"><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 di=
r=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 29 September 2013 =
19:52, Vincent Jacquet <span dir=3D"ltr">&lt;<a>vjac...@flowgroup.fr</a>&gt=
;</span> wrote:<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 dir=3D"ltr"><br><div=
>We are not talking about implementing a little utility class in your progr=
am, where you can nicely encapsulate all those memory issues in a class. We=
 are talking about adding a class to the standard library for which you hav=
e no idea how people will use and misuse it. And it is just so tempting to =
simply move this class around because it is cheap... <br>

<br></div></div></blockquote><div><br></div><div>Well, we actually think we=
 do know how people will use and misuse it, since equivalent<br>types have =
actual practical use experience. <br></div></div><br></div></div>
</blockquote></div></div></div><div class=3D""><div class=3D"h5">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a1134c928286ec604e7895ec3--

.

--nextPart6450240.0yejI3oW4L
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On domingo, 29 de setembro de 2013 02:44:32, Vincent Jacquet wrote:
> What I do not agree, is the "non-owning part". This is unsafe *by design*
> and I believe we could achieve the same kind of performance by having the
> first instance taking ownership of the data and then sharing it among its
> substrings. This is safe *by design*.

I really doubt that you can "achieve the same kind of performance by hanving
the first instance taking ownership of the data". You're free to prove me
wrong, though.

A string_view, just like QStringRef, is just a pointer and two iterators (or
two index positions, or one index and one size). This type will most likely
have trivial copy constructors and a trivial destructor, and a constexpr
constructor. As such, it's really, *really* cheap to pass and return.

If the string_view contained a shared_ptr member, the copy- and move-
constructors and the destructor would be non-trivial. Even if we assume a
proper move-return, there's a small code expansion for the destructor. What's
more, the constructor would definitely not be constexpr, since it needs to
create a shared_ptr.

And here it gets worse: shared_ptr must allocate memory. This, alone, probably
negates the entire benefit of the performance optimisation.

To put a final nail on this coffin: your suggestion doesn't work without copying
the string. This is undefined behaviour:

[from <fc8e6e50-634d-4547-aa5f-0e6c5eb87f6b@isocpp.org>]

template <class T, class Traits = char_traits<T>, class Alloc =
allocator<T>>
class basic_stick
{
    shared_ptr<const basic_string<T,Traits,Alloc>> ptr;
    size_t pos;
    size_t count;

public:
    basic_stick(basic_string<T,Traits,Alloc>&& s)
        : ptr(s), pos(0), count(ptr->size())
    {}
}; // ### see note [*]

The simplest use would be:

struct X
{
    double d; // just for padding
    string s;
    basic_stick<char> f() { return basic_stick<char>(s); }
};

Note how the returned value now contains a shared_ptr pointing to something
that was not allocated with new. It's 8 bytes inside a structure. You can't
take a shared_ptr to that...

To *own* the string, this class needs to create a copy. The best class to
contain a copy of a std::string's contents is called std::string.


[*] this class does not compile. You need to fix the constructor to pass a
pointer to shared_ptr, not a reference. Then you need to add a constructor
that takes an lvalue reference so the example above works.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart6450240.0yejI3oW4L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBSSHjHM/XwBW70U1gRAgY2AKCWgO13Mek5owxAGuOZdMYPN35gDwCfRS/n
N+pj1tgXFz/hav0+egVlsUE=
=G7fB
-----END PGP SIGNATURE-----

--nextPart6450240.0yejI3oW4L--


.

------=_Part_2072_19876981.1380484655863
Content-Type: text/plain; charset=ISO-8859-1

Silly me, I forgot the make_shared.
You have made a good point with the trivial constructor and destructor. I
assumed most of the time would be spent in the copy of the string. It's
problably right with big strings but it is definitively worth benchmarking
on smaller one.

Thanks for taking the time.

On Sunday, September 29, 2013 9:00:16 PM UTC+2, Thiago Macieira wrote:
>
> On domingo, 29 de setembro de 2013 02:44:32, Vincent Jacquet wrote:
> > What I do not agree, is the "non-owning part". This is unsafe *by
> design*
> > and I believe we could achieve the same kind of performance by having
> the
> > first instance taking ownership of the data and then sharing it among
> its
> > substrings. This is safe *by design*.
>
> I really doubt that you can "achieve the same kind of performance by
> hanving
> the first instance taking ownership of the data". You're free to prove me
> wrong, though.
>
> A string_view, just like QStringRef, is just a pointer and two iterators
> (or
> two index positions, or one index and one size). This type will most
> likely
> have trivial copy constructors and a trivial destructor, and a constexpr
> constructor. As such, it's really, *really* cheap to pass and return.
>
> If the string_view contained a shared_ptr member, the copy- and move-
> constructors and the destructor would be non-trivial. Even if we assume a
> proper move-return, there's a small code expansion for the destructor.
> What's
> more, the constructor would definitely not be constexpr, since it needs to
> create a shared_ptr.
>
> And here it gets worse: shared_ptr must allocate memory. This, alone,
> probably
> negates the entire benefit of the performance optimisation.
>
> To put a final nail on this coffin: your suggestion doesn't work without
> copying
> the string. This is undefined behaviour:
>
>
> template <class T, class Traits = char_traits<T>, class Alloc =
> allocator<T>>
> class basic_stick
> {
>     shared_ptr<const basic_string<T,Traits,Alloc>> ptr;
>     size_t pos;
>     size_t count;
>
> public:
>     basic_stick(basic_string<T,Traits,Alloc>&& s)
>         : ptr(s), pos(0), count(ptr->size())
>     {}
> }; // ### see note [*]
>
> The simplest use would be:
>
> struct X
> {
>     double d; // just for padding
>     string s;
>     basic_stick<char> f() { return basic_stick<char>(s); }
> };
>
> Note how the returned value now contains a shared_ptr pointing to
> something
> that was not allocated with new. It's 8 bytes inside a structure. You
> can't
> take a shared_ptr to that...
>
> To *own* the string, this class needs to create a copy. The best class to
> contain a copy of a std::string's contents is called std::string.
>
>
> [*] this class does not compile. You need to fix the constructor to pass a
> pointer to shared_ptr, not a reference. Then you need to add a constructor
> that takes an lvalue reference so the example above works.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>

--

---
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_2072_19876981.1380484655863
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Silly me, I forgot the make_shared. <br>You have made a go=
od point with the trivial constructor and destructor. I assumed most of the=
 time would be spent in the copy of the string. It's problably right with b=
ig strings but it is definitively worth benchmarking on smaller one.<br><br=
>Thanks for taking the time.<br><br>On Sunday, September 29, 2013 9:00:16 P=
M UTC+2, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>On domingo, 29 de setembro de 2013 02:44:32, Vincent Jacquet wrote:
<br>&gt; What I do not agree, is the "non-owning part". This is unsafe *by =
design*=20
<br>&gt; and I believe we could achieve the same kind of performance by hav=
ing the=20
<br>&gt; first instance taking ownership of the data and then sharing it am=
ong its=20
<br>&gt; substrings. This is safe *by design*.
<br>
<br>I really doubt that you can "achieve the same kind of performance by ha=
nving=20
<br>the first instance taking ownership of the data". You're free to prove =
me=20
<br>wrong, though.
<br>
<br>A string_view, just like QStringRef, is just a pointer and two iterator=
s (or=20
<br>two index positions, or one index and one size). This type will most li=
kely=20
<br>have trivial copy constructors and a trivial destructor, and a constexp=
r=20
<br>constructor. As such, it's really, *really* cheap to pass and return.
<br>
<br>If the string_view contained a shared_ptr member, the copy- and move-
<br>constructors and the destructor would be non-trivial. Even if we assume=
 a=20
<br>proper move-return, there's a small code expansion for the destructor. =
What's=20
<br>more, the constructor would definitely not be constexpr, since it needs=
 to=20
<br>create a shared_ptr.
<br>
<br>And here it gets worse: shared_ptr must allocate memory. This, alone, p=
robably=20
<br>negates the entire benefit of the performance optimisation.
<br>
<br>To put a final nail on this coffin: your suggestion doesn't work withou=
t copying=20
<br>the string. This is undefined behaviour:
<br>
<br><br>template &lt;class T, class Traits =3D char_traits&lt;T&gt;, class =
Alloc =3D=20
<br>allocator&lt;T&gt;&gt;
<br>class basic_stick
<br>{
<br>&nbsp; &nbsp; shared_ptr&lt;const basic_string&lt;T,Traits,Alloc&gt;&gt=
; ptr;
<br>&nbsp; &nbsp; size_t pos;
<br>&nbsp; &nbsp; size_t count;
<br>
<br>public:
<br>&nbsp; &nbsp; basic_stick(basic_string&lt;T,<wbr>Traits,Alloc&gt;&amp;&=
amp; s)
<br>&nbsp; &nbsp; &nbsp; &nbsp; : ptr(s), pos(0), count(ptr-&gt;size())
<br>&nbsp; &nbsp; {}
<br>}; // ### see note [*]
<br>
<br>The simplest use would be:
<br>
<br>struct X
<br>{
<br>&nbsp; &nbsp; double d; // just for padding
<br>&nbsp; &nbsp; string s;
<br>&nbsp; &nbsp; basic_stick&lt;char&gt; f() { return basic_stick&lt;char&=
gt;(s); }
<br>};
<br>
<br>Note how the returned value now contains a shared_ptr pointing to somet=
hing=20
<br>that was not allocated with new. It's 8 bytes inside a structure. You c=
an't=20
<br>take a shared_ptr to that...
<br>
<br>To *own* the string, this class needs to create a copy. The best class =
to=20
<br>contain a copy of a std::string's contents is called std::string.
<br>
<br>
<br>[*] this class does not compile. You need to fix the constructor to pas=
s a=20
<br>pointer to shared_ptr, not a reference. Then you need to add a construc=
tor=20
<br>that takes an lvalue reference so the example above works.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2072_19876981.1380484655863--

.

------=_Part_0_1380489319223
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline

It should also be noted that COW strings were banned in C++11, so the proposed solution would still have ownership issues.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Vincent Jacquet" <vjacquet@flowgroup.fr>
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Use cases for string_view (N3762)?
Date: Sun, Sep 29, 2013 12:57 PM

Silly me, I forgot the make_shared.
You have made a good point with the trivial constructor and destructor. I assumed most of the time would be spent in the copy of the string. It's problably right with big strings but it is definitively worth benchmarking on smaller one.

Thanks for taking the time.

On Sunday, September 29, 2013 9:00:16 PM UTC+2, Thiago Macieira wrote:On domingo, 29 de setembro de 2013 02:44:32, Vincent Jacquet wrote:

> What I do not agree, is the "non-owning part". This is unsafe *by design*

> and I believe we could achieve the same kind of performance by having the

> first instance taking ownership of the data and then sharing it among its

> substrings. This is safe *by design*.



I really doubt that you can "achieve the same kind of performance by hanving

the first instance taking ownership of the data". You're free to prove me

wrong, though.



A string_view, just like QStringRef, is just a pointer and two iterators (or

two index positions, or one index and one size). This type will most likely

have trivial copy constructors and a trivial destructor, and a constexpr

constructor. As such, it's really, *really* cheap to pass and return.



If the string_view contained a shared_ptr member, the copy- and move-

constructors and the destructor would be non-trivial. Even if we assume a

proper move-return, there's a small code expansion for the destructor. What's

more, the constructor would definitely not be constexpr, since it needs to

create a shared_ptr.



And here it gets worse: shared_ptr must allocate memory. This, alone, probably

negates the entire benefit of the performance optimisation.



To put a final nail on this coffin: your suggestion doesn't work without copying

the string. This is undefined behaviour:




template <class T, class Traits = char_traits<T>, class Alloc =

allocator<T>>

class basic_stick

{

shared_ptr<const basic_string<T,Traits,Alloc>> ptr;

size_t pos;

size_t count;



public:

basic_stick(basic_string<T,Traits,Alloc>&& s)

: ptr(s), pos(0), count(ptr->size())

{}

}; // ### see note [*]



The simplest use would be:



struct X

{

double d; // just for padding

string s;

basic_stick<char> f() { return basic_stick<char>(s); }

};



Note how the returned value now contains a shared_ptr pointing to something

that was not allocated with new. It's 8 bytes inside a structure. You can't

take a shared_ptr to that...



To *own* the string, this class needs to create a copy. The best class to

contain a copy of a std::string's contents is called std::string.





[*] this class does not compile. You need to fix the constructor to pass a

pointer to shared_ptr, not a reference. Then you need to add a constructor

that takes an lvalue reference so the example above works.

--

Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org

Software Architect - Intel Open Source Technology Center

PGP/GPG: 0x6EF45358; fingerprint:

E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358






--

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

--

---
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_0_1380489319223
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>It sh=
ould also be noted that COW strings were banned in C++11, so the proposed s=
olution would still have ownership issues.</div><div><br></div><div>Sent fr=
om a touchscreen. Please excuse the brevity and tpyos.</div><br><div id=3D"=
htc_header">----- Reply message -----<br>From: &quot;Vincent Jacquet&quot; =
&lt;vjacquet@flowgroup.fr&gt;<br>To: &lt;std-proposals@isocpp.org&gt;<br>Su=
bject: [std-proposals] Use cases for string_view (N3762)?<br>Date: Sun, Sep=
 29, 2013 12:57 PM</div></div><br><div dir=3D"ltr">Silly me, I forgot the m=
ake_shared. <br>You have made a good point with the trivial constructor and=
 destructor. I assumed most of the time would be spent in the copy of the s=
tring. It's problably right with big strings but it is definitively worth b=
enchmarking on smaller one.<br><br>Thanks for taking the time.<br><br>On Su=
nday, September 29, 2013 9:00:16 PM UTC+2, Thiago Macieira wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On domingo, 29 de setembro de 2013 02:44=
:32, Vincent Jacquet wrote:
<br>&gt; What I do not agree, is the "non-owning part". This is unsafe *by =
design*=20
<br>&gt; and I believe we could achieve the same kind of performance by hav=
ing the=20
<br>&gt; first instance taking ownership of the data and then sharing it am=
ong its=20
<br>&gt; substrings. This is safe *by design*.
<br>
<br>I really doubt that you can "achieve the same kind of performance by ha=
nving=20
<br>the first instance taking ownership of the data". You're free to prove =
me=20
<br>wrong, though.
<br>
<br>A string_view, just like QStringRef, is just a pointer and two iterator=
s (or=20
<br>two index positions, or one index and one size). This type will most li=
kely=20
<br>have trivial copy constructors and a trivial destructor, and a constexp=
r=20
<br>constructor. As such, it's really, *really* cheap to pass and return.
<br>
<br>If the string_view contained a shared_ptr member, the copy- and move-
<br>constructors and the destructor would be non-trivial. Even if we assume=
 a=20
<br>proper move-return, there's a small code expansion for the destructor. =
What's=20
<br>more, the constructor would definitely not be constexpr, since it needs=
 to=20
<br>create a shared_ptr.
<br>
<br>And here it gets worse: shared_ptr must allocate memory. This, alone, p=
robably=20
<br>negates the entire benefit of the performance optimisation.
<br>
<br>To put a final nail on this coffin: your suggestion doesn't work withou=
t copying=20
<br>the string. This is undefined behaviour:
<br>
<br><br>template &lt;class T, class Traits =3D char_traits&lt;T&gt;, class =
Alloc =3D=20
<br>allocator&lt;T&gt;&gt;
<br>class basic_stick
<br>{
<br>&nbsp; &nbsp; shared_ptr&lt;const basic_string&lt;T,Traits,Alloc&gt;&gt=
; ptr;
<br>&nbsp; &nbsp; size_t pos;
<br>&nbsp; &nbsp; size_t count;
<br>
<br>public:
<br>&nbsp; &nbsp; basic_stick(basic_string&lt;T,<wbr>Traits,Alloc&gt;&amp;&=
amp; s)
<br>&nbsp; &nbsp; &nbsp; &nbsp; : ptr(s), pos(0), count(ptr-&gt;size())
<br>&nbsp; &nbsp; {}
<br>}; // ### see note [*]
<br>
<br>The simplest use would be:
<br>
<br>struct X
<br>{
<br>&nbsp; &nbsp; double d; // just for padding
<br>&nbsp; &nbsp; string s;
<br>&nbsp; &nbsp; basic_stick&lt;char&gt; f() { return basic_stick&lt;char&=
gt;(s); }
<br>};
<br>
<br>Note how the returned value now contains a shared_ptr pointing to somet=
hing=20
<br>that was not allocated with new. It's 8 bytes inside a structure. You c=
an't=20
<br>take a shared_ptr to that...
<br>
<br>To *own* the string, this class needs to create a copy. The best class =
to=20
<br>contain a copy of a std::string's contents is called std::string.
<br>
<br>
<br>[*] this class does not compile. You need to fix the constructor to pas=
s a=20
<br>pointer to shared_ptr, not a reference. Then you need to add a construc=
tor=20
<br>that takes an lvalue reference so the example above works.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_0_1380489319223--


.

------=_Part_181_9833377.1380492352083
Content-Type: text/plain; charset=ISO-8859-1

There is no copy (the intent was a move) and no write. Where do you see COW
?

On Sunday, September 29, 2013 11:15:19 PM UTC+2, Billy O'Neal wrote:
>
> It should also be noted that COW strings were banned in C++11, so the
> proposed solution would still have ownership issues.
>
> Sent from a touchscreen. Please excuse the brevity and tpyos.
>
> ----- Reply message -----
> From: "Vincent Jacquet" <vjac...@flowgroup.fr <javascript:>>
> To: <std-pr...@isocpp.org <javascript:>>
> Subject: [std-proposals] Use cases for string_view (N3762)?
> Date: Sun, Sep 29, 2013 12:57 PM
>
> Silly me, I forgot the make_shared.
> You have made a good point with the trivial constructor and destructor. I
> assumed most of the time would be spent in the copy of the string. It's
> problably right with big strings but it is definitively worth benchmarking
> on smaller one.
>
> Thanks for taking the time.
>
> On Sunday, September 29, 2013 9:00:16 PM UTC+2, Thiago Macieira wrote:
>>
>> On domingo, 29 de setembro de 2013 02:44:32, Vincent Jacquet wrote:
>> > What I do not agree, is the "non-owning part". This is unsafe *by
>> design*
>> > and I believe we could achieve the same kind of performance by having
>> the
>> > first instance taking ownership of the data and then sharing it among
>> its
>> > substrings. This is safe *by design*.
>>
>> I really doubt that you can "achieve the same kind of performance by
>> hanving
>> the first instance taking ownership of the data". You're free to prove me
>> wrong, though.
>>
>> A string_view, just like QStringRef, is just a pointer and two iterators
>> (or
>> two index positions, or one index and one size). This type will most
>> likely
>> have trivial copy constructors and a trivial destructor, and a constexpr
>> constructor. As such, it's really, *really* cheap to pass and return.
>>
>> If the string_view contained a shared_ptr member, the copy- and move-
>> constructors and the destructor would be non-trivial. Even if we assume a
>> proper move-return, there's a small code expansion for the destructor.
>> What's
>> more, the constructor would definitely not be constexpr, since it needs
>> to
>> create a shared_ptr.
>>
>> And here it gets worse: shared_ptr must allocate memory. This, alone,
>> probably
>> negates the entire benefit of the performance optimisation.
>>
>> To put a final nail on this coffin: your suggestion doesn't work without
>> copying
>> the string. This is undefined behaviour:
>>
>>
>> template <class T, class Traits = char_traits<T>, class Alloc =
>> allocator<T>>
>> class basic_stick
>> {
>>     shared_ptr<const basic_string<T,Traits,Alloc>> ptr;
>>     size_t pos;
>>     size_t count;
>>
>> public:
>>     basic_stick(basic_string<T,Traits,Alloc>&& s)
>>         : ptr(s), pos(0), count(ptr->size())
>>     {}
>> }; // ### see note [*]
>>
>> The simplest use would be:
>>
>> struct X
>> {
>>     double d; // just for padding
>>     string s;
>>     basic_stick<char> f() { return basic_stick<char>(s); }
>> };
>>
>> Note how the returned value now contains a shared_ptr pointing to
>> something
>> that was not allocated with new. It's 8 bytes inside a structure. You
>> can't
>> take a shared_ptr to that...
>>
>> To *own* the string, this class needs to create a copy. The best class to
>> contain a copy of a std::string's contents is called std::string.
>>
>>
>> [*] this class does not compile. You need to fix the constructor to pass
>> a
>> pointer to shared_ptr, not a reference. Then you need to add a
>> constructor
>> that takes an lvalue reference so the example above works.
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>       PGP/GPG: 0x6EF45358; fingerprint:
>>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>>
>  --
>
> ---
> 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-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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_181_9833377.1380492352083
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There is no copy (the intent was a move) and no write. Whe=
re do you see COW ?<br><br>On Sunday, September 29, 2013 11:15:19 PM UTC+2,=
 Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"font-size:12pt;font-family:Calibri,sans-serif"><div>It should also be n=
oted that COW strings were banned in C++11, so the proposed solution would =
still have ownership issues.</div><div><br></div><div>Sent from a touchscre=
en. Please excuse the brevity and tpyos.</div><br><div>----- Reply message =
-----<br>From: "Vincent Jacquet" &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"UmpVNBysUJoJ">vjac...@flowgroup.fr</a>&gt;<br>=
To: &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
UmpVNBysUJoJ">std-pr...@isocpp.org</a>&gt;<br>Subject: [std-proposals] Use =
cases for string_view (N3762)?<br>Date: Sun, Sep 29, 2013 12:57 PM</div></d=
iv><br><div dir=3D"ltr">Silly me, I forgot the make_shared. <br>You have ma=
de a good point with the trivial constructor and destructor. I assumed most=
 of the time would be spent in the copy of the string. It's problably right=
 with big strings but it is definitively worth benchmarking on smaller one.=
<br><br>Thanks for taking the time.<br><br>On Sunday, September 29, 2013 9:=
00:16 PM UTC+2, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x">On domingo, 29 de setembro de 2013 02:44:32, Vincent Jacquet wrote:
<br>&gt; What I do not agree, is the "non-owning part". This is unsafe *by =
design*=20
<br>&gt; and I believe we could achieve the same kind of performance by hav=
ing the=20
<br>&gt; first instance taking ownership of the data and then sharing it am=
ong its=20
<br>&gt; substrings. This is safe *by design*.
<br>
<br>I really doubt that you can "achieve the same kind of performance by ha=
nving=20
<br>the first instance taking ownership of the data". You're free to prove =
me=20
<br>wrong, though.
<br>
<br>A string_view, just like QStringRef, is just a pointer and two iterator=
s (or=20
<br>two index positions, or one index and one size). This type will most li=
kely=20
<br>have trivial copy constructors and a trivial destructor, and a constexp=
r=20
<br>constructor. As such, it's really, *really* cheap to pass and return.
<br>
<br>If the string_view contained a shared_ptr member, the copy- and move-
<br>constructors and the destructor would be non-trivial. Even if we assume=
 a=20
<br>proper move-return, there's a small code expansion for the destructor. =
What's=20
<br>more, the constructor would definitely not be constexpr, since it needs=
 to=20
<br>create a shared_ptr.
<br>
<br>And here it gets worse: shared_ptr must allocate memory. This, alone, p=
robably=20
<br>negates the entire benefit of the performance optimisation.
<br>
<br>To put a final nail on this coffin: your suggestion doesn't work withou=
t copying=20
<br>the string. This is undefined behaviour:
<br>
<br><br>template &lt;class T, class Traits =3D char_traits&lt;T&gt;, class =
Alloc =3D=20
<br>allocator&lt;T&gt;&gt;
<br>class basic_stick
<br>{
<br>&nbsp; &nbsp; shared_ptr&lt;const basic_string&lt;T,Traits,Alloc&gt;&gt=
; ptr;
<br>&nbsp; &nbsp; size_t pos;
<br>&nbsp; &nbsp; size_t count;
<br>
<br>public:
<br>&nbsp; &nbsp; basic_stick(basic_string&lt;T,<wbr>Traits,Alloc&gt;&amp;&=
amp; s)
<br>&nbsp; &nbsp; &nbsp; &nbsp; : ptr(s), pos(0), count(ptr-&gt;size())
<br>&nbsp; &nbsp; {}
<br>}; // ### see note [*]
<br>
<br>The simplest use would be:
<br>
<br>struct X
<br>{
<br>&nbsp; &nbsp; double d; // just for padding
<br>&nbsp; &nbsp; string s;
<br>&nbsp; &nbsp; basic_stick&lt;char&gt; f() { return basic_stick&lt;char&=
gt;(s); }
<br>};
<br>
<br>Note how the returned value now contains a shared_ptr pointing to somet=
hing=20
<br>that was not allocated with new. It's 8 bytes inside a structure. You c=
an't=20
<br>take a shared_ptr to that...
<br>
<br>To *own* the string, this class needs to create a copy. The best class =
to=20
<br>contain a copy of a std::string's contents is called std::string.
<br>
<br>
<br>[*] this class does not compile. You need to fix the constructor to pas=
s a=20
<br>pointer to shared_ptr, not a reference. Then you need to add a construc=
tor=20
<br>that takes an lvalue reference so the example above works.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br></blockquote></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
UmpVNBysUJoJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"UmpVNBysUJoJ">std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_181_9833377.1380492352083--

.

--90e6ba614dbe42442204e78d0942
Content-Type: text/plain; charset=ISO-8859-1

If there is no copy, and no COW, how does the string_view get an owning
reference to the string data? The API isn't any more "safe" if you store
the string_view somewhere and the caller is able to mutate the underlying
guts. Giving the string_view an owning reference to the data in the
std::string implies copying of the string's data, or COW inside string.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sun, Sep 29, 2013 at 3:05 PM, Vincent Jacquet <vjacquet@flowgroup.fr>wrote:

> There is no copy (the intent was a move) and no write. Where do you see
> COW ?
>
>
> On Sunday, September 29, 2013 11:15:19 PM UTC+2, Billy O'Neal wrote:
>
>> It should also be noted that COW strings were banned in C++11, so the
>> proposed solution would still have ownership issues.
>>
>> Sent from a touchscreen. Please excuse the brevity and tpyos.
>>
>> ----- Reply message -----
>> From: "Vincent Jacquet" <vjac...@flowgroup.fr>
>> To: <std-pr...@isocpp.org>
>> Subject: [std-proposals] Use cases for string_view (N3762)?
>> Date: Sun, Sep 29, 2013 12:57 PM
>>
>> Silly me, I forgot the make_shared.
>> You have made a good point with the trivial constructor and destructor. I
>> assumed most of the time would be spent in the copy of the string. It's
>> problably right with big strings but it is definitively worth benchmarking
>> on smaller one.
>>
>> Thanks for taking the time.
>>
>> On Sunday, September 29, 2013 9:00:16 PM UTC+2, Thiago Macieira wrote:
>>>
>>> On domingo, 29 de setembro de 2013 02:44:32, Vincent Jacquet wrote:
>>> > What I do not agree, is the "non-owning part". This is unsafe *by
>>> design*
>>> > and I believe we could achieve the same kind of performance by having
>>> the
>>> > first instance taking ownership of the data and then sharing it among
>>> its
>>> > substrings. This is safe *by design*.
>>>
>>> I really doubt that you can "achieve the same kind of performance by
>>> hanving
>>> the first instance taking ownership of the data". You're free to prove
>>> me
>>> wrong, though.
>>>
>>> A string_view, just like QStringRef, is just a pointer and two iterators
>>> (or
>>> two index positions, or one index and one size). This type will most
>>> likely
>>> have trivial copy constructors and a trivial destructor, and a constexpr
>>> constructor. As such, it's really, *really* cheap to pass and return.
>>>
>>> If the string_view contained a shared_ptr member, the copy- and move-
>>> constructors and the destructor would be non-trivial. Even if we assume
>>> a
>>> proper move-return, there's a small code expansion for the destructor.
>>> What's
>>> more, the constructor would definitely not be constexpr, since it needs
>>> to
>>> create a shared_ptr.
>>>
>>> And here it gets worse: shared_ptr must allocate memory. This, alone,
>>> probably
>>> negates the entire benefit of the performance optimisation.
>>>
>>> To put a final nail on this coffin: your suggestion doesn't work without
>>> copying
>>> the string. This is undefined behaviour:
>>>
>>>
>>> template <class T, class Traits = char_traits<T>, class Alloc =
>>> allocator<T>>
>>> class basic_stick
>>> {
>>>     shared_ptr<const basic_string<T,Traits,Alloc>> ptr;
>>>     size_t pos;
>>>     size_t count;
>>>
>>> public:
>>>     basic_stick(basic_string<T,**Traits,Alloc>&& s)
>>>         : ptr(s), pos(0), count(ptr->size())
>>>     {}
>>> }; // ### see note [*]
>>>
>>> The simplest use would be:
>>>
>>> struct X
>>> {
>>>     double d; // just for padding
>>>     string s;
>>>     basic_stick<char> f() { return basic_stick<char>(s); }
>>> };
>>>
>>> Note how the returned value now contains a shared_ptr pointing to
>>> something
>>> that was not allocated with new. It's 8 bytes inside a structure. You
>>> can't
>>> take a shared_ptr to that...
>>>
>>> To *own* the string, this class needs to create a copy. The best class
>>> to
>>> contain a copy of a std::string's contents is called std::string.
>>>
>>>
>>> [*] this class does not compile. You need to fix the constructor to pass
>>> a
>>> pointer to shared_ptr, not a reference. Then you need to add a
>>> constructor
>>> that takes an lvalue reference so the example above works.
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>    Software Architect - Intel Open Source Technology Center
>>>       PGP/GPG: 0x6EF45358; fingerprint:
>>>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>>>
>>  --
>>
>> ---
>> 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-proposal...@**isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>>
>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-**
>> proposals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>>
>  --
>
> ---
> 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/.
>

--

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

--90e6ba614dbe42442204e78d0942
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>If there is no copy, and no COW, how does the string_=
view get an owning reference to the string data? The API isn&#39;t any more=
 &quot;safe&quot; if you store the string_view somewhere and the caller is =
able to mutate the underlying guts. Giving the string_view an owning refere=
nce to the data in the std::string implies copying of the string&#39;s data=
, or COW inside string.</div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Sep 29, 2013 at 3:05 PM, Vincent=
 Jacquet <span dir=3D"ltr">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" tar=
get=3D"_blank">vjacquet@flowgroup.fr</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bor=
der-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:sol=
id">


<div dir=3D"ltr">There is no copy (the intent was a move) and no write. Whe=
re do you see COW ?<div><br><br>On Sunday, September 29, 2013 11:15:19 PM U=
TC+2, Billy O&#39;Neal wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">


<div style=3D"font-family:Calibri,sans-serif;font-size:12pt"><div><div>It s=
hould also be noted that COW strings were banned in C++11, so the proposed =
solution would still have ownership issues.</div><div><br></div>
<div>Sent from a touchscreen. Please excuse the brevity and tpyos.</div><br=
></div><div><div><div>----- Reply message -----<br>From: &quot;Vincent Jacq=
uet&quot; &lt;<a>vjac...@flowgroup.fr</a>&gt;<br>To: &lt;<a>std-pr...@isocp=
p.org</a>&gt;<br>


Subject: [std-proposals] Use cases for string_view (N3762)?<br>Date: Sun, S=
ep 29, 2013 12:57 PM</div></div></div></div><div><div><br><div dir=3D"ltr">=
Silly me, I forgot the make_shared. <br>You have made a good point with the=
 trivial constructor and destructor. I assumed most of the time would be sp=
ent in the copy of the string. It&#39;s problably right with big strings bu=
t it is definitively worth benchmarking on smaller one.<br>


<br>Thanks for taking the time.<br><br>On Sunday, September 29, 2013 9:00:1=
6 PM UTC+2, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">


On domingo, 29 de setembro de 2013 02:44:32, Vincent Jacquet wrote:
<br>&gt; What I do not agree, is the &quot;non-owning part&quot;. This is u=
nsafe *by design*=20
<br>&gt; and I believe we could achieve the same kind of performance by hav=
ing the=20
<br>&gt; first instance taking ownership of the data and then sharing it am=
ong its=20
<br>&gt; substrings. This is safe *by design*.
<br>
<br>I really doubt that you can &quot;achieve the same kind of performance =
by hanving=20
<br>the first instance taking ownership of the data&quot;. You&#39;re free =
to prove me=20
<br>wrong, though.
<br>
<br>A string_view, just like QStringRef, is just a pointer and two iterator=
s (or=20
<br>two index positions, or one index and one size). This type will most li=
kely=20
<br>have trivial copy constructors and a trivial destructor, and a constexp=
r=20
<br>constructor. As such, it&#39;s really, *really* cheap to pass and retur=
n.
<br>
<br>If the string_view contained a shared_ptr member, the copy- and move-
<br>constructors and the destructor would be non-trivial. Even if we assume=
 a=20
<br>proper move-return, there&#39;s a small code expansion for the destruct=
or. What&#39;s=20
<br>more, the constructor would definitely not be constexpr, since it needs=
 to=20
<br>create a shared_ptr.
<br>
<br>And here it gets worse: shared_ptr must allocate memory. This, alone, p=
robably=20
<br>negates the entire benefit of the performance optimisation.
<br>
<br>To put a final nail on this coffin: your suggestion doesn&#39;t work wi=
thout copying=20
<br>the string. This is undefined behaviour:
<br>
<br><br>template &lt;class T, class Traits =3D char_traits&lt;T&gt;, class =
Alloc =3D=20
<br>allocator&lt;T&gt;&gt;
<br>class basic_stick
<br>{
<br>=A0 =A0 shared_ptr&lt;const basic_string&lt;T,Traits,Alloc&gt;&gt; ptr;
<br>=A0 =A0 size_t pos;
<br>=A0 =A0 size_t count;
<br>
<br>public:
<br>=A0 =A0 basic_stick(basic_string&lt;T,<u></u>Traits,Alloc&gt;&amp;&amp;=
 s)
<br>=A0 =A0 =A0 =A0 : ptr(s), pos(0), count(ptr-&gt;size())
<br>=A0 =A0 {}
<br>}; // ### see note [*]
<br>
<br>The simplest use would be:
<br>
<br>struct X
<br>{
<br>=A0 =A0 double d; // just for padding
<br>=A0 =A0 string s;
<br>=A0 =A0 basic_stick&lt;char&gt; f() { return basic_stick&lt;char&gt;(s)=
; }
<br>};
<br>
<br>Note how the returned value now contains a shared_ptr pointing to somet=
hing=20
<br>that was not allocated with new. It&#39;s 8 bytes inside a structure. Y=
ou can&#39;t=20
<br>take a shared_ptr to that...
<br>
<br>To *own* the string, this class needs to create a copy. The best class =
to=20
<br>contain a copy of a std::string&#39;s contents is called std::string.
<br>
<br>
<br>[*] this class does not compile. You need to fix the constructor to pas=
s a=20
<br>pointer to shared_ptr, not a reference. Then you need to add a construc=
tor=20
<br>that takes an lvalue reference so the example above works.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>=A0 =A0Software Architect - Intel Open Source Technology Center
<br>=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358
<br></blockquote></div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div><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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></blockquote></div><div><div>

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--90e6ba614dbe42442204e78d0942--

.

On domingo, 29 de setembro de 2013 15:05:51, Vincent Jacquet wrote:
> There is no copy (the intent was a move) and no write. Where do you see COW
> ?

In the part where I said that it would have to copy the string in order to
have the first owning copy, since COW is prohibited.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

On Sun, Sep 29, 2013 at 3:20 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On domingo, 29 de setembro de 2013 15:05:51, Vincent Jacquet wrote:
>> There is no copy (the intent was a move) and no write. Where do you see COW
>> ?
>
> In the part where I said that it would have to copy the string in order to
> have the first owning copy, since COW is prohibited.

This sounds like a frozen_string or immutable_string design, where you
could move a std::string into it, after which it's refcounted, and
substrings are cheap. That would be a useful class, which could fit
into a future standard. However, it fills a different niche than
string_view, which was originally designed as a way to let functions
take either const char* or std::string as arguments, and which also
works well for parsing and substring operations when you know the
string's going to stay alive anyway.

--

---
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_28_25259982.1380889916417
Content-Type: text/plain; charset=ISO-8859-1

Something like string_view is absolutely essential to designing efficient
text parsers. You can add me to the list of someone who has had to do it
before.
Currently the only way to do this is with const char*. Not only is it
somewhat ugly throwing character pointers all over the place, we also need
to stop
wasting the worlds cpu time computing strlen().

Having a non-owning reference to an object in general can dangerous, but
C++ is not a guaranteed memory safe language.
Not everything needs a shared_ptr, indeed thats why we use C++ for that
extra ounce of efficiency not
possible by safer runtime environments. If you want to throw shared_ptr
like semantics everywhere, then
you're just reimplementing a poor mans garbage collector.

There are 3 major classes of lifetimes that I can think of:
1) Shared (shared_ptr, COW strings, garbage collectors)
2) Unique (unique_ptr, std::string)
3) Owned by someone else (const char*, sting_view, iterator, T&, const T&)

Memory safe languages only give you (1) which has performance penalties. If
you want strong memory safety then
why are you using C++ with all of its horrible complexity? We have (2) now
with unique_ptr but need more of (3) to
take advantage of the performance benefits of unique ownership.

My question about string_view is how do we safety use it with legacy
interfaces requiring null terminated strings?
What are some good guidelines? This could confuse a lot of people.


On Sunday, September 29, 2013 8:28:36 PM UTC-4, Jeffrey Yasskin wrote:
>
> On Sun, Sep 29, 2013 at 3:20 PM, Thiago Macieira <thi...@macieira.org<javascript:>>
> wrote:
> > On domingo, 29 de setembro de 2013 15:05:51, Vincent Jacquet wrote:
> >> There is no copy (the intent was a move) and no write. Where do you see
> COW
> >> ?
> >
> > In the part where I said that it would have to copy the string in order
> to
> > have the first owning copy, since COW is prohibited.
>
> This sounds like a frozen_string or immutable_string design, where you
> could move a std::string into it, after which it's refcounted, and
> substrings are cheap. That would be a useful class, which could fit
> into a future standard. However, it fills a different niche than
> string_view, which was originally designed as a way to let functions
> take either const char* or std::string as arguments, and which also
> works well for parsing and substring operations when you know the
> string's going to stay alive anyway.
>

--

---
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_28_25259982.1380889916417
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Something like string_view is absolutely essential to desi=
gning efficient text parsers. You can add me to the list of someone who has=
 had to do it before.<div>Currently the only way to do this is with const c=
har*. Not only is it somewhat ugly throwing character pointers all over the=
 place, we also need to stop</div><div>wasting the worlds cpu time computin=
g strlen().</div><div><div><br></div><div>Having a non-owning reference to =
an object in general can dangerous, but C++ is not a guaranteed memory safe=
 language.</div><div>Not everything needs a shared_ptr, indeed thats why we=
 use C++ for that extra ounce of efficiency not</div><div>possible by safer=
 runtime environments. If you want to throw shared_ptr like semantics every=
where, then</div><div>you're just reimplementing a poor mans garbage collec=
tor.</div><div><br></div><div>There are 3 major classes of lifetimes that I=
 can think of:</div><div>1) Shared (shared_ptr, COW strings, garbage collec=
tors)</div><div>2) Unique (unique_ptr, std::string)</div><div>3) Owned by s=
omeone else (const char*, sting_view, iterator, T&amp;, const T&amp;)</div>=
<div><br></div><div>Memory safe languages only give you (1) which has perfo=
rmance penalties. If you want strong memory safety then</div><div>why are y=
ou using C++ with all of its horrible complexity? We have (2) now with uniq=
ue_ptr but need more of (3) to</div><div>take advantage of the performance =
benefits of unique ownership.</div><div><br></div><div>My question about st=
ring_view is how do we safety use it with legacy interfaces requiring null =
terminated strings?</div><div>What are some good guidelines? This could con=
fuse a lot of people.</div><div><br></div><div><br>On Sunday, September 29,=
 2013 8:28:36 PM UTC-4, Jeffrey Yasskin wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">On Sun, Sep 29, 2013 at 3:20 PM, Thiago Macieira &lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"3xr5T5haN4YJ">=
thi...@macieira.org</a>&gt; wrote:
<br>&gt; On domingo, 29 de setembro de 2013 15:05:51, Vincent Jacquet wrote=
:
<br>&gt;&gt; There is no copy (the intent was a move) and no write. Where d=
o you see COW
<br>&gt;&gt; ?
<br>&gt;
<br>&gt; In the part where I said that it would have to copy the string in =
order to
<br>&gt; have the first owning copy, since COW is prohibited.
<br>
<br>This sounds like a frozen_string or immutable_string design, where you
<br>could move a std::string into it, after which it's refcounted, and
<br>substrings are cheap. That would be a useful class, which could fit
<br>into a future standard. However, it fills a different niche than
<br>string_view, which was originally designed as a way to let functions
<br>take either const char* or std::string as arguments, and which also
<br>works well for parsing and substring operations when you know the
<br>string's going to stay alive anyway.
<br></blockquote></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_28_25259982.1380889916417--

.

On sexta-feira, 4 de outubro de 2013 05:31:56, fmatthew5876@gmail.com wrote:
> My question about string_view is how do we safety use it with legacy
> interfaces requiring null terminated strings?
> What are some good guidelines? This could confuse a lot of people.

That's why string_view cannot have a c_str() member. If you need a null-
terminated string, you'll need to get an owning reference first via
std::string, which will add the null for you.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--bcaec51820f29dc83404e7ece7a2
Content-Type: text/plain; charset=ISO-8859-1

Well, if you didn't allow cutting off the end, then having .c_str() would
be entirely possible, given that all of string_view's targets are null
terminated inputs.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Oct 4, 2013 at 9:09 AM, Thiago Macieira <thiago@macieira.org> wrote:

> On sexta-feira, 4 de outubro de 2013 05:31:56, fmatthew5876@gmail.comwrote:
> > My question about string_view is how do we safety use it with legacy
> > interfaces requiring null terminated strings?
> > What are some good guidelines? This could confuse a lot of people.
>
> That's why string_view cannot have a c_str() member. If you need a null-
> terminated string, you'll need to get an owning reference first via
> std::string, which will add the null for you.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.
>

--

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

--bcaec51820f29dc83404e7ece7a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well, if you didn&#39;t allow cutting off the end, then ha=
ving .c_str() would be entirely possible, given that all of string_view&#39=
;s targets are null terminated inputs.</div><div class=3D"gmail_extra"><br =
clear=3D"all">

<div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 9:09 AM, Thiago M=
acieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=
=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"im">On sexta-feira, 4 de outubro de 2013 05:31:56, <a href=3D=
"mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</a> wrote:<br>
&gt; My question about string_view is how do we safety use it with legacy<b=
r>
&gt; interfaces requiring null terminated strings?<br>
&gt; What are some good guidelines? This could confuse a lot of people.<br>
<br>
</div>That&#39;s why string_view cannot have a c_str() member. If you need =
a null-<br>
terminated string, you&#39;ll need to get an owning reference first via<br>
std::string, which will add the null for you.<br>
<div class=3D"im HOEnZb"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--bcaec51820f29dc83404e7ece7a2--

.

2013/10/4 Billy O'Neal <billy.oneal@gmail.com>:
> Well, if you didn't allow cutting off the end, then having .c_str() would be
> entirely possible, given that all of string_view's targets are null
> terminated inputs.

char c1[] {'a'};

is also a valid target, thus not null-terminated.

- Daniel

--

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

.

--089e0129478414bb9604e7ed9f2c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Doesn't string_view's constructor not do the moral equivalent of strlen for
that case? I wouldn't expect that to be valid.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Oct 4, 2013 at 9:40 AM, Daniel Kr=FCgler <daniel.kruegler@gmail.com=
>wrote:

> 2013/10/4 Billy O'Neal <billy.oneal@gmail.com>:
> > Well, if you didn't allow cutting off the end, then having .c_str()
> would be
> > entirely possible, given that all of string_view's targets are null
> > terminated inputs.
>
> char c1[] {'a'};
>
> is also a valid target, thus not null-terminated.
>
> - Daniel
>
> --
>
> ---
> 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/.
>

--=20

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

--089e0129478414bb9604e7ed9f2c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Doesn&#39;t string_view&#39;s constructor not do the =
moral equivalent of strlen for that case? I wouldn&#39;t expect that to be =
valid.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div di=
r=3D"ltr">

<div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 9:40 AM, Daniel K=
r=FCgler <span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com"=
 target=3D"_blank">daniel.kruegler@gmail.com</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">

2013/10/4 Billy O&#39;Neal &lt;<a href=3D"mailto:billy.oneal@gmail.com">bil=
ly.oneal@gmail.com</a>&gt;:<br>
<div class=3D"im">&gt; Well, if you didn&#39;t allow cutting off the end, t=
hen having .c_str() would be<br>
&gt; entirely possible, given that all of string_view&#39;s targets are nul=
l<br>
&gt; terminated inputs.<br>
<br>
</div>char c1[] {&#39;a&#39;};<br>
<br>
is also a valid target, thus not null-terminated.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Daniel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0129478414bb9604e7ed9f2c--

.

2013/10/4 Billy O'Neal <billy.oneal@gmail.com>:
> Doesn't string_view's constructor not do the moral equivalent of strlen for
> that case? I wouldn't expect that to be valid.

It is valid. string_view has different constructors, among them

basic_string_view(const charT* str);

for nullterminated strings, but also

constexpr basic_string_view(const charT* str, size_type len);

for not necessarily nullterminated ones.

There is only one requirement that holds for all: The pointer is not a
null pointer.

- Daniel

--

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

.

--047d7b2e133914080904e7edb19e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>but also
>constexpr basic_string_view(const charT* str, size_type len);

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Oct 4, 2013 at 10:31 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com>wrote:

> 2013/10/4 Billy O'Neal <billy.oneal@gmail.com>:
> > Doesn't string_view's constructor not do the moral equivalent of strlen
> for
> > that case? I wouldn't expect that to be valid.
>
> It is valid. string_view has different constructors, among them
>
> basic_string_view(const charT* str);
>
> for nullterminated strings, but also
>
> constexpr basic_string_view(const charT* str, size_type len);
>
> for not necessarily nullterminated ones.
>
> There is only one requirement that holds for all: The pointer is not a
> null pointer.
>
> - Daniel
>
> --
>
> ---
> 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/.
>

--=20

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

--047d7b2e133914080904e7edb19e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;but also<br>&gt;constexpr basic_string_view(const char=
T* str, size_type len);</div><div class=3D"gmail_extra"><br clear=3D"all"><=
div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bit=
bucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a=
></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 10:31 AM, Daniel =
Kr=FCgler <span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com=
" target=3D"_blank">daniel.kruegler@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">

<div class=3D"im">2013/10/4 Billy O&#39;Neal &lt;<a href=3D"mailto:billy.on=
eal@gmail.com">billy.oneal@gmail.com</a>&gt;:<br>
</div><div class=3D"im">&gt; Doesn&#39;t string_view&#39;s constructor not =
do the moral equivalent of strlen for<br>
&gt; that case? I wouldn&#39;t expect that to be valid.<br>
<br>
</div>It is valid. string_view has different constructors, among them<br>
<br>
basic_string_view(const charT* str);<br>
<br>
for nullterminated strings, but also<br>
<br>
constexpr basic_string_view(const charT* str, size_type len);<br>
<br>
for not necessarily nullterminated ones.<br>
<br>
There is only one requirement that holds for all: The pointer is not a<br>
null pointer.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
- Daniel<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b2e133914080904e7edb19e--

.

--001a11c2d6aa4b60a904e7edb939
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>but also
>constexpr basic_string_view(const charT* str, size_type len);

I believe that is there because the interface allows chopping off the end.
It would be entirely reasonable to not have a constructor of that form.

This is just a trade off. I think the proposal (which doesn't require null
termination) is fine -- I'm just saying that an implementation which does
require null termination and thus can cough up a null terminated string
cheaply is also entirely reasonable / possible.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Oct 4, 2013 at 10:31 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com>wrote:

> 2013/10/4 Billy O'Neal <billy.oneal@gmail.com>:
> > Doesn't string_view's constructor not do the moral equivalent of strlen
> for
> > that case? I wouldn't expect that to be valid.
>
> It is valid. string_view has different constructors, among them
>
> basic_string_view(const charT* str);
>
> for nullterminated strings, but also
>
> constexpr basic_string_view(const charT* str, size_type len);
>
> for not necessarily nullterminated ones.
>
> There is only one requirement that holds for all: The pointer is not a
> null pointer.
>
> - Daniel
>
> --
>
> ---
> 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/.
>

--=20

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

--001a11c2d6aa4b60a904e7edb939
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt;but also<br>&gt;constexpr basic_string_view(const=
 charT* str, size_type len);</div><div>=A0</div><div>I believe that is ther=
e because the interface allows chopping off the end. It would be entirely r=
easonable to not have a constructor of that form.</div>

<div>=A0</div><div>This is just a trade off. I think the proposal (which do=
esn&#39;t require null termination) is fine -- I&#39;m just saying that an =
implementation which does require null termination and thus can cough up a =
null terminated string cheaply is also entirely reasonable / possible.</div=
>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 10:31 AM, Daniel =
Kr=FCgler <span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com=
" target=3D"_blank">daniel.kruegler@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">

<div class=3D"im">2013/10/4 Billy O&#39;Neal &lt;<a href=3D"mailto:billy.on=
eal@gmail.com">billy.oneal@gmail.com</a>&gt;:<br>
</div><div class=3D"im">&gt; Doesn&#39;t string_view&#39;s constructor not =
do the moral equivalent of strlen for<br>
&gt; that case? I wouldn&#39;t expect that to be valid.<br>
<br>
</div>It is valid. string_view has different constructors, among them<br>
<br>
basic_string_view(const charT* str);<br>
<br>
for nullterminated strings, but also<br>
<br>
constexpr basic_string_view(const charT* str, size_type len);<br>
<br>
for not necessarily nullterminated ones.<br>
<br>
There is only one requirement that holds for all: The pointer is not a<br>
null pointer.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
- Daniel<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2d6aa4b60a904e7edb939--

.

On sexta-feira, 4 de outubro de 2013 10:34:27, Billy O'Neal wrote:
> I believe that is there because the interface allows chopping off the end.
> It would be entirely reasonable to not have a constructor of that form.
>
> This is just a trade off. I think the proposal (which doesn't require null
> termination) is fine -- I'm just saying that an implementation which does
> require null termination and thus can cough up a null terminated string
> cheaply is also entirely reasonable / possible.

I strongly disagree.

No implementation must require a null. string_view must be able to point to an
arbitrary set of charT in memory, without requiring a null at the end.

It can require that no null is in the middle.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--90e6ba6e89cef167b704e7edd8ce
Content-Type: text/plain; charset=ISO-8859-1

Yes, according to the proposal. However, several "string_view ish"
implementations out there do not allow chopping off the end, do require
null, and as a result can cheaply give you null termination. This is
nothing more than a design tradeoff. The proposal has chosen to allow
chopping the end off at the expense of not being able to provide cheap
backcompat with C APIs.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Oct 4, 2013 at 10:38 AM, Thiago Macieira <thiago@macieira.org>wrote:

> On sexta-feira, 4 de outubro de 2013 10:34:27, Billy O'Neal wrote:
> > I believe that is there because the interface allows chopping off the
> end.
> > It would be entirely reasonable to not have a constructor of that form.
> >
> > This is just a trade off. I think the proposal (which doesn't require
> null
> > termination) is fine -- I'm just saying that an implementation which does
> > require null termination and thus can cough up a null terminated string
> > cheaply is also entirely reasonable / possible.
>
> I strongly disagree.
>
> No implementation must require a null. string_view must be able to point
> to an
> arbitrary set of charT in memory, without requiring a null at the end.
>
> It can require that no null is in the middle.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.
>

--

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

--90e6ba6e89cef167b704e7edd8ce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, according to the proposal. However, several &quot;str=
ing_view ish&quot; implementations out there do not allow chopping off the =
end, do require null, and as a result can cheaply give you null termination=
.. This is nothing more than a design tradeoff. The proposal has chosen to a=
llow chopping the end off at the expense of not being able to provide cheap=
 backcompat with C APIs.</div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 10:38 AM, Thiago =
Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" targe=
t=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"im">On sexta-feira, 4 de outubro de 2013 10:34:27, Billy O&#3=
9;Neal wrote:<br>
&gt; I believe that is there because the interface allows chopping off the =
end.<br>
&gt; It would be entirely reasonable to not have a constructor of that form=
..<br>
&gt;<br>
&gt; This is just a trade off. I think the proposal (which doesn&#39;t requ=
ire null<br>
&gt; termination) is fine -- I&#39;m just saying that an implementation whi=
ch does<br>
&gt; require null termination and thus can cough up a null terminated strin=
g<br>
&gt; cheaply is also entirely reasonable / possible.<br>
<br>
</div>I strongly disagree.<br>
<br>
No implementation must require a null. string_view must be able to point to=
 an<br>
arbitrary set of charT in memory, without requiring a null at the end.<br>
<br>
It can require that no null is in the middle.<br>
<div class=3D"im HOEnZb"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--90e6ba6e89cef167b704e7edd8ce--

.

--047d7bdc0934656c2a04e7edf461
Content-Type: text/plain; charset=ISO-8859-1

On 4 October 2013 12:34, Billy O'Neal <billy.oneal@gmail.com> wrote:

> >but also
> >constexpr basic_string_view(const charT* str, size_type len);
>
> I believe that is there because the interface allows chopping off the end.
> It would be entirely reasonable to not have a constructor of that form.
>

But that would make string_view only marginally better than const char*.
If you want it for interfaces that are '\0'-terminated, by definition you
don't need the length.

And I wouldn't want to pass a string_view to something that isn't looking
at the length, because in general embedded '\0' characters are perfectly
okay.
--
 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/.

--047d7bdc0934656c2a04e7edf461
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 4 October 2013 12:34, Billy O&#39;Neal <span dir=3D"ltr=
">&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.onea=
l@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 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><div>&gt;=
but also<br>&gt;constexpr basic_string_view(const charT* str, size_type len=
);</div>

<div>=A0</div></div><div>I believe that is there because the interface allo=
ws chopping off the end. It would be entirely reasonable to not have a cons=
tructor of that form.</div></div></blockquote><div><br></div><div>But that =
would make string_view only marginally better than const char*.=A0 If you w=
ant it for interfaces that are &#39;\0&#39;-terminated, by definition you d=
on&#39;t need the length.<br>

<br></div><div>And I wouldn&#39;t want to pass a string_view to something t=
hat isn&#39;t looking at the length, because in general embedded &#39;\0&#3=
9; characters are perfectly okay.<br></div></div>-- <br>=A0Nevin &quot;:-)&=
quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bdc0934656c2a04e7edf461--

.

On Fri, 2013-10-04 at 10:38 -0700, Thiago Macieira wrote:
> On sexta-feira, 4 de outubro de 2013 10:34:27, Billy O'Neal wrote:
> > I believe that is there because the interface allows chopping off the end.
> > It would be entirely reasonable to not have a constructor of that form.
> >
> > This is just a trade off. I think the proposal (which doesn't require null
> > termination) is fine -- I'm just saying that an implementation which does
> > require null termination and thus can cough up a null terminated string
> > cheaply is also entirely reasonable / possible.
>
> I strongly disagree.
>
> No implementation must require a null. string_view must be able to point to an
> arbitrary set of charT in memory, without requiring a null at the end.
>
> It can require that no null is in the middle.

I strongly disagree.

One of the best parts of std::string is that it can contain any octets
and I would be really disappointed if std::string_view reintroduced the
mistake that is the trailing NUL character.

If you wish to use functions taking C strings then string_view isn't for
you but that is part of the cost.

/MF

--

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

.

On sexta-feira, 4 de outubro de 2013 19:54:11, Magnus Fromreide wrote:
> > It can require that no null is in the middle.
>
> I strongly disagree.

Fair enough. Nulls in the middle are fine to me :-)

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--047d7b2e1339d0a7a504e7f096af
Content-Type: text/plain; charset=ISO-8859-1

Why is why I'm not saying the proposed string_view is a bad idea. I'm just
saying that this is a design tradeoff. I've been in situations like this on
a regular basis:

class IWrapC
{
public:
    void DoStuff(std::string const& str)
    {
        ::PlatformDoStuff(str.c_str());
    }
};

where one doesn't want to expose a const char* (and force all callers to
call c_str() or similar if they have std::string s) but doesn't necessarily
want to pay the construction cost of a std::string if a const char* is all
the caller has.

If I can have only one or the other, I'd probably do what the standard
proposal is here that allows arbitrary substring operations, and doesn't
give quick null termination. But cases where the other way are better
can/do exist.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Oct 4, 2013 at 10:51 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 4 October 2013 12:34, Billy O'Neal <billy.oneal@gmail.com> wrote:
>
>> >but also
>> >constexpr basic_string_view(const charT* str, size_type len);
>>
>> I believe that is there because the interface allows chopping off the
>> end. It would be entirely reasonable to not have a constructor of that form.
>>
>
> But that would make string_view only marginally better than const char*.
> If you want it for interfaces that are '\0'-terminated, by definition you
> don't need the length.
>
> And I wouldn't want to pass a string_view to something that isn't looking
> at the length, because in general embedded '\0' characters are perfectly
> okay.
> --
>  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/.
>

--

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

--047d7b2e1339d0a7a504e7f096af
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Why is why I&#39;m not saying the proposed string_view is =
a bad idea. I&#39;m just saying that this is a design tradeoff. I&#39;ve be=
en in situations like this on a regular basis:<div><br></div><div><div>clas=
s IWrapC</div>

<div>{</div><div>public:</div><div>=A0 =A0 void DoStuff(std::string const&a=
mp; str)</div><div>=A0 =A0 {</div><div>=A0 =A0 =A0 =A0 ::PlatformDoStuff(st=
r.c_str());</div><div>=A0 =A0 }</div><div>};</div></div><div><br></div><div=
>where one doesn&#39;t want to expose a const char* (and force all callers =
to call c_str() or similar if they have std::string s) but doesn&#39;t nece=
ssarily want to pay the construction cost of a std::string if a const char*=
 is all the caller has.</div>

<div><br></div><div>If I can have only one or the other, I&#39;d probably d=
o what the standard proposal is here that allows arbitrary substring operat=
ions, and doesn&#39;t give quick null termination. But cases where the othe=
r way are better can/do exist.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 10:51 AM, Nevin L=
iber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

<div dir=3D"ltr"><div class=3D"im">On 4 October 2013 12:34, Billy O&#39;Nea=
l <span dir=3D"ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"=
_blank">billy.oneal@gmail.com</a>&gt;</span> wrote:<br></div><div class=3D"=
gmail_extra">

<div class=3D"gmail_quote"><div class=3D"im">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>&gt;but also<br>&=
gt;constexpr basic_string_view(const charT* str, size_type len);</div>

<div>=A0</div></div><div>I believe that is there because the interface allo=
ws chopping off the end. It would be entirely reasonable to not have a cons=
tructor of that form.</div></div></blockquote><div><br></div></div><div>

But that would make string_view only marginally better than const char*.=A0=
 If you want it for interfaces that are &#39;\0&#39;-terminated, by definit=
ion you don&#39;t need the length.<br>

<br></div><div>And I wouldn&#39;t want to pass a string_view to something t=
hat isn&#39;t looking at the length, because in general embedded &#39;\0&#3=
9; characters are perfectly okay.<br></div></div><div class=3D"im">-- <br>

=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 <a href=3D"=
tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 69=
1-1404</a>
</div></div></div>

<p></p>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b2e1339d0a7a504e7f096af--

.

--047d7bdc979c048b2d04e7f0c7a3
Content-Type: text/plain; charset=ISO-8859-1

On 4 October 2013 15:59, Billy O'Neal <billy.oneal@gmail.com> wrote:

> Why is why I'm not saying the proposed string_view is a bad idea. I'm just
> saying that this is a design tradeoff. I've been in situations like this on
> a regular basis:
>
> class IWrapC
> {
> public:
>     void DoStuff(std::string const& str)
>     {
>         ::PlatformDoStuff(str.c_str());
>     }
> };
>
> where one doesn't want to expose a const char* (and force all callers to
> call c_str() or similar if they have std::string s) but doesn't necessarily
> want to pay the construction cost of a std::string if a const char* is all
> the caller has.
>

Write a pair of free functions?

const char* c_str_view(const char* s) { return s; }
const char* c_str_view(std::string const& s) { return s.c_str(); }

Make it an object if it makes you feel better:

struct c_str_view
{
    c_str_view(const char* s) : s_(s) {}
    c_str_view(std::string const& s) : s_(s.c_str()) {}

    operator const char*() const noexcept { return s_; }

private:
    const char* s_;
}

I don't see why anything like this needs to be in the standard.  The
standard cannot cover every possible use case.
--
 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/.

--047d7bdc979c048b2d04e7f0c7a3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 4 October 2013 15:59, Billy O&#39;Neal <span dir=3D"ltr=
">&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.onea=
l@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 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Why is why I&#39;m not sayi=
ng the proposed string_view is a bad idea. I&#39;m just saying that this is=
 a design tradeoff. I&#39;ve been in situations like this on a regular basi=
s:<div>

<br></div><div><div>class IWrapC</div>

<div>{</div><div>public:</div><div>=A0 =A0 void DoStuff(std::string const&a=
mp; str)</div><div>=A0 =A0 {</div><div>=A0 =A0 =A0 =A0 ::PlatformDoStuff(st=
r.c_str());</div><div>=A0 =A0 }</div><div>};</div></div><div><br></div><div=
>where one doesn&#39;t want to expose a const char* (and force all callers =
to call c_str() or similar if they have std::string s) but doesn&#39;t nece=
ssarily want to pay the construction cost of a std::string if a const char*=
 is all the caller has.</div>

</div></blockquote><div><br></div><div>Write a pair of free functions?<br><=
br></div><div>const char* c_str_view(const char* s) { return s; }<br></div>=
<div>const char* c_str_view(std::string const&amp; s) { return s.c_str(); }=
<br>

<br></div><div>Make it an object if it makes you feel better:<br><br></div>=
<div>struct c_str_view<br>{<br></div><div>=A0=A0=A0 c_str_view(const char* =
s) : s_(s) {}<br></div><div>=A0=A0=A0 c_str_view(std::string const&amp; s) =
: s_(s.c_str()) {}<br>

<br></div><div>=A0=A0=A0 operator const char*() const noexcept { return s_;=
 }<br><br></div><div>private:<br></div><div>=A0=A0=A0 const char* s_;<br></=
div><div>}<br></div><div><br></div><div>I don&#39;t see why anything like t=
his needs to be in the standard.=A0 The standard cannot cover every possibl=
e use case.<br clear=3D"all">

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bdc979c048b2d04e7f0c7a3--

.

--20cf303ea90a8f5aae04e7f0d343
Content-Type: text/plain; charset=ISO-8859-1

I never said I wanted it in the standard.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Oct 4, 2013 at 2:13 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 4 October 2013 15:59, Billy O'Neal <billy.oneal@gmail.com> wrote:
>
>> Why is why I'm not saying the proposed string_view is a bad idea. I'm
>> just saying that this is a design tradeoff. I've been in situations like
>> this on a regular basis:
>>
>> class IWrapC
>> {
>> public:
>>     void DoStuff(std::string const& str)
>>     {
>>         ::PlatformDoStuff(str.c_str());
>>     }
>> };
>>
>> where one doesn't want to expose a const char* (and force all callers to
>> call c_str() or similar if they have std::string s) but doesn't necessarily
>> want to pay the construction cost of a std::string if a const char* is all
>> the caller has.
>>
>
> Write a pair of free functions?
>
> const char* c_str_view(const char* s) { return s; }
> const char* c_str_view(std::string const& s) { return s.c_str(); }
>
> Make it an object if it makes you feel better:
>
> struct c_str_view
> {
>     c_str_view(const char* s) : s_(s) {}
>     c_str_view(std::string const& s) : s_(s.c_str()) {}
>
>     operator const char*() const noexcept { return s_; }
>
> private:
>     const char* s_;
> }
>
> I don't see why anything like this needs to be in the standard.  The
> standard cannot cover every possible use case.
> --
>  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/.
>

--

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

--20cf303ea90a8f5aae04e7f0d343
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I never said I wanted it in the standard.</div><div class=
=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;N=
eal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blan=
k">https://github.com/BillyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 2:13 PM, Nevin Li=
ber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

<div dir=3D"ltr"><div class=3D"im">On 4 October 2013 15:59, Billy O&#39;Nea=
l <span dir=3D"ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"=
_blank">billy.oneal@gmail.com</a>&gt;</span> wrote:<br></div><div class=3D"=
gmail_extra">

<div class=3D"gmail_quote"><div class=3D"im">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Why is why I&#39;m not sayi=
ng the proposed string_view is a bad idea. I&#39;m just saying that this is=
 a design tradeoff. I&#39;ve been in situations like this on a regular basi=
s:<div>



<br></div><div><div>class IWrapC</div>

<div>{</div><div>public:</div><div>=A0 =A0 void DoStuff(std::string const&a=
mp; str)</div><div>=A0 =A0 {</div><div>=A0 =A0 =A0 =A0 ::PlatformDoStuff(st=
r.c_str());</div><div>=A0 =A0 }</div><div>};</div></div><div><br></div><div=
>where one doesn&#39;t want to expose a const char* (and force all callers =
to call c_str() or similar if they have std::string s) but doesn&#39;t nece=
ssarily want to pay the construction cost of a std::string if a const char*=
 is all the caller has.</div>



</div></blockquote><div><br></div></div><div>Write a pair of free functions=
?<br><br></div><div>const char* c_str_view(const char* s) { return s; }<br>=
</div><div>const char* c_str_view(std::string const&amp; s) { return s.c_st=
r(); }<br>



<br></div><div>Make it an object if it makes you feel better:<br><br></div>=
<div>struct c_str_view<br>{<br></div><div>=A0=A0=A0 c_str_view(const char* =
s) : s_(s) {}<br></div><div>=A0=A0=A0 c_str_view(std::string const&amp; s) =
: s_(s.c_str()) {}<br>



<br></div><div>=A0=A0=A0 operator const char*() const noexcept { return s_;=
 }<br><br></div><div>private:<br></div><div>=A0=A0=A0 const char* s_;<br></=
div><div>}<br></div><div><br></div><div>I don&#39;t see why anything like t=
his needs to be in the standard.=A0 The standard cannot cover every possibl=
e use case.<br clear=3D"all">



</div></div><div class=3D"im">-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18=
476911404" target=3D"_blank">(847) 691-1404</a>
</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--20cf303ea90a8f5aae04e7f0d343--

.

--001a1133b3e4063f9504e7f0e26a
Content-Type: text/plain; charset=ISO-8859-1

On 4 October 2013 16:16, Billy O'Neal <billy.oneal@gmail.com> wrote:

> I never said I wanted it in the standard.
>

Er, this is std-proposals...
--
 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/.

--001a1133b3e4063f9504e7f0e26a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 4 October 2013 16:16, Billy O&#39;Neal <span dir=3D"ltr=
">&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.onea=
l@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 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I never said I wanted it in=
 the standard.<br></div></blockquote><div><br></div><div>Er, this is std-pr=
oposals... <br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a1133b3e4063f9504e7f0e26a--

.

--001a11c3a8cc8d781a04e7f1f4ae
Content-Type: text/plain; charset=ISO-8859-1

I was responding to a comment saying that it would be "impossible" to have
string_view cheaply return a null terminated string. All I was saying was
that this was a design tradeoff, and explained quite clearly that the
inability to cheaply return NTBSs comes directly from the ability to
support substring operations. I'm not commenting on the validity of the
direction taken by the proposers of that document, nor of the committee. (I
think they made the right move anyway)

It is important to acknowledge design compromises, because making one thing
easy often makes other things difficult. Good design is the art of
minimizing the bad-ness, and part of that is acknowledging where the
bad-ness lies.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Oct 4, 2013 at 2:20 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 4 October 2013 16:16, Billy O'Neal <billy.oneal@gmail.com> wrote:
>
>> I never said I wanted it in the standard.
>>
>
> Er, this is std-proposals...
> --
>  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/.
>

--

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

--001a11c3a8cc8d781a04e7f1f4ae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I was responding to a comment saying that it would be &quo=
t;impossible&quot; to have string_view cheaply return a null terminated str=
ing. All I was saying was that this was a design tradeoff, and explained qu=
ite clearly that the inability to cheaply return NTBSs comes directly from =
the ability to support substring operations. I&#39;m not commenting on the =
validity of the direction taken by the proposers of that document, nor of t=
he committee. (I think they made the right move anyway)<div>

<br></div><div>It is important to acknowledge design compromises, because m=
aking one thing easy often makes other things difficult. Good design is the=
 art of minimizing the bad-ness, and part of that is acknowledging where th=
e bad-ness lies.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 2:20 PM, Nevin Li=
ber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

<div dir=3D"ltr"><div class=3D"im">On 4 October 2013 16:16, Billy O&#39;Nea=
l <span dir=3D"ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"=
_blank">billy.oneal@gmail.com</a>&gt;</span> wrote:<br></div><div class=3D"=
gmail_extra">

<div class=3D"gmail_quote"><div class=3D"im">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I never said I wanted it in=
 the standard.<br></div></blockquote><div><br></div></div><div>Er, this is =
std-proposals... <br>



</div></div><div class=3D"im">-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18=
476911404" target=3D"_blank">(847) 691-1404</a>
</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c3a8cc8d781a04e7f1f4ae--

.

------=_Part_1124_6616182.1380926459565
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Friday, October 4, 2013 8:31:56 AM UTC-4, fmatth...@gmail.com wrote:
>
> =85My question about string_view is how do we safety use it with legacy=
=20
> interfaces requiring null terminated strings?
> What are some good guidelines? This could confuse a lot of people.
>

I wrote a different implementation of a similar type. It does not require=
=20
termination, and the end is the only position where a terminator may exist.

The API allows you to query if the character sequence is terminated. It=20
also allows you to create a std::string from the character sequence.

This allows you to slice/truncate without any reallocation, but you may=20
need to create a new std::string when you need to pass a null-terminated=20
string.

I also made a small type for terminated, externally owned character=20
sequences which represent strings.

So the approach I took was to provide a convenience function which creates=
=20
a std::string when a null terminated representation is required. Obviously,=
=20
APIs can be designed to minimize this promotion, where required. Maybe the=
=20
proposed implementation does this as well, IDK.

--=20

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

------=_Part_1124_6616182.1380926459565
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 4, 2013 8:31:56 AM UTC-4, fmatth...@gma=
il.com 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">=
<div><div>=85My question about string_view is how do we safety use it with =
legacy interfaces requiring null terminated strings?</div><div>What are som=
e good guidelines? This could confuse a lot of people.</div></div></div></b=
lockquote><div><br></div><div>I wrote a different implementation of a simil=
ar type. It does not require termination, and the end is the only position =
where a terminator may exist.</div><div><br></div><div>The API allows you t=
o query if the character sequence is terminated. It also allows you to crea=
te a std::string from the character sequence.</div><div><br></div><div>This=
 allows you to slice/truncate without any reallocation, but you may need to=
 create a new std::string when you need to pass a null-terminated string.</=
div><div><br></div><div>I also made a small type for terminated, externally=
 owned character sequences which represent strings.</div><div><br></div><di=
v>So the approach I took was to provide a convenience function which create=
s a std::string when a null terminated representation is required. Obviousl=
y, APIs can be designed to minimize this promotion, where required. Maybe t=
he proposed implementation does this as well, IDK.</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1124_6616182.1380926459565--

.

------=_Part_1360_372440.1380945512566
Content-Type: text/plain; charset=ISO-8859-1

string_view *cannot* be compatible with null terminated strings. Its
impossible.

string_view can be used to get a read only substring reference to another
string. In fact null termination would be a huge problem becuase then it
would have to inadvertently modify the parent string. It would be almost
impossible to use correctly.

My only concern is that we're stuck with legacy C apis that use const char*
arguments.

At the very least (maybe through a separate proposal), we should get
string_view versions of all of the const char* methods in the library.
Particularly things like stdtod, atoi, fstream::open, etc..

One day I'd like to see the death of strlen().

--

---
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_1360_372440.1380945512566
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">string_view *cannot* be compatible with null terminated st=
rings. Its impossible.<div><br></div><div>string_view can be used to get a =
read only substring reference to another string. In fact null termination w=
ould be a huge problem becuase then it would have to inadvertently modify t=
he parent string. It would be almost impossible to use correctly.</div><div=
><br></div><div>My only concern is that we're stuck with legacy C apis that=
 use const char* arguments.&nbsp;</div><div><br></div><div>At the very leas=
t (maybe through a separate proposal), we should get string_view versions o=
f all of the const char* methods in the library. Particularly things like s=
tdtod, atoi, fstream::open, etc..&nbsp;</div><div><br></div><div>One day I'=
d like to see the death of strlen().&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1360_372440.1380945512566--

.

--20cf303e9e6e9da5ec04e7f7afe1
Content-Type: text/plain; charset=ISO-8859-1

I believe I just demonstrated that it can, at the expensive of losing
substring operations. And again, I'm not advocating that it should -- I
think substring operations are more useful than c_str() for something in
the standard library.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Oct 4, 2013 at 8:58 PM, <fmatthew5876@gmail.com> wrote:

> string_view *cannot* be compatible with null terminated strings. Its
> impossible.
>
> string_view can be used to get a read only substring reference to another
> string. In fact null termination would be a huge problem becuase then it
> would have to inadvertently modify the parent string. It would be almost
> impossible to use correctly.
>
> My only concern is that we're stuck with legacy C apis that use const
> char* arguments.
>
> At the very least (maybe through a separate proposal), we should get
> string_view versions of all of the const char* methods in the library.
> Particularly things like stdtod, atoi, fstream::open, etc..
>
> One day I'd like to see the death of strlen().
>
> --
>
> ---
> 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/.
>

--

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

--20cf303e9e6e9da5ec04e7f7afe1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I believe I just demonstrated that it can, at the expensiv=
e of losing substring operations. And again, I&#39;m not advocating that it=
 should -- I think substring operations are more useful than c_str() for so=
mething in the standard library.</div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 8:58 PM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">=
fmatthew5876@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">

<div dir=3D"ltr">string_view *cannot* be compatible with null terminated st=
rings. Its impossible.<div><br></div><div>string_view can be used to get a =
read only substring reference to another string. In fact null termination w=
ould be a huge problem becuase then it would have to inadvertently modify t=
he parent string. It would be almost impossible to use correctly.</div>

<div><br></div><div>My only concern is that we&#39;re stuck with legacy C a=
pis that use const char* arguments.=A0</div><div><br></div><div>At the very=
 least (maybe through a separate proposal), we should get string_view versi=
ons of all of the const char* methods in the library. Particularly things l=
ike stdtod, atoi, fstream::open, etc..=A0</div>

<div><br></div><div>One day I&#39;d like to see the death of strlen().=A0</=
div></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--20cf303e9e6e9da5ec04e7f7afe1--

.

------=_Part_795_7854743.1380955483465
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Il giorno venerd=EC 4 ottobre 2013 22:59:34 UTC+2, Billy O'Neal ha scritto:
>
> Why is why I'm not saying the proposed string_view is a bad idea. I'm jus=
t=20
> saying that this is a design tradeoff. I've been in situations like this =
on=20
> a regular basis:
>

actually, this tradeoff cost can be mitigated by usage: note that you can=
=20
preserve null-termination when passing a c-string to a string_view, eg

class IWrapC
{
public:
    void DoStuff( std::string_view str )
    {
        ::PlatformDoStuff( str.back() ? std::string( str ).c_str() :=20
str.data() );
    }
};

// IWrapC c; ... c.DoStuff( std::string_view( my_c_string,=20
strlen(my_c_string) + 1 ) );

clearly, this won't work with substrings, but no other non-copying solution=
=20
would either ( so nothing to trade off ) ...=20

--=20

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

------=_Part_795_7854743.1380955483465
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Il giorno venerd=EC 4 ottobre 2013 22:59:34 UTC+2, Billy O=
'Neal ha scritto:<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">Why is why I'm not saying the proposed string_view is a bad idea. I'm j=
ust saying that this is a design tradeoff. I've been in situations like thi=
s on a regular basis:</div></blockquote><div><br>actually, this tradeoff co=
st can be mitigated by usage: note that you can preserve null-termination w=
hen passing a c-string to a string_view, eg<br><br>class IWrapC<br>{<br>pub=
lic:<br>&nbsp;&nbsp;&nbsp; void DoStuff( std::string_view str )<br>&nbsp;&n=
bsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::PlatformDoStuf=
f( str.back() ? std::string( str ).c_str() : str.data() );<br>&nbsp;&nbsp;&=
nbsp; }<br>};<br><br>// IWrapC c; ... c.DoStuff( std::string_view( my_c_str=
ing, strlen(my_c_string) + 1 ) );<br><br>clearly, this won't work with subs=
trings, but no other non-copying solution would either ( so nothing to trad=
e off ) ... <br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_795_7854743.1380955483465--

.

On 05/10/2013 00:37, Billy O'Neal wrote:
> I was responding to a comment saying that it would be "impossible" to
> have string_view cheaply return a null terminated string. All I was
> saying was that this was a design tradeoff, and explained quite
> clearly that the inability to cheaply return NTBSs comes directly from
> the ability to support substring operations.
I don't think it is the ability of supporting substring operations on
the string_view which is the issue, it is the ability to construct a
string_view from any existing substrings, of a std::string, of an NUL
terminated C string, of an array of characters...  The parser use case
which came so often as the problem aimed to be solved by string_view is
in the last situation: we have read a whole file in one operation, it is
now just a consecutive set of characters in memory and we want
string_views from part of it.

Yours,

--
Jean-Marc

--

---
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_1652_33277821.1380985731437
Content-Type: text/plain; charset=ISO-8859-1

On Friday, October 4, 2013 7:43:19 PM UTC+2, Billy O'Neal wrote:

> Yes, according to the proposal. However, several "string_view ish"
> implementations out there do not allow chopping off the end, do require
> null, and as a result can cheaply give you null termination. This is
> nothing more than a design tradeoff. The proposal has chosen to allow
> chopping the end off at the expense of not being able to provide cheap
> backcompat with C APIs.
>
> Kinda true, an additional zstring_view would still be possible if it's a
frequent use 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1652_33277821.1380985731437
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 4, 2013 7:43:19 PM UTC+2, Billy O'Neal =
wrote:<br><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">Yes=
, according to the proposal. However, several "string_view ish" implementat=
ions out there do not allow chopping off the end, do require null, and as a=
 result can cheaply give you null termination. This is nothing more than a =
design tradeoff. The proposal has chosen to allow chopping the end off at t=
he expense of not being able to provide cheap backcompat with C APIs.</div>

<div><br></div></blockquote><div>Kinda true, an additional zstring_view wou=
ld still be possible if it's a frequent use case.&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1652_33277821.1380985731437--

.

------=_Part_1286_8430705.1380988470921
Content-Type: text/plain; charset=ISO-8859-1

There are many problems with null termination:
1) substr, splicing, and any other size mutating operations requires
mutability because it has write a null byte. string_view must then take
char* arguments in its constructors instead of const char*. It must also
have a char* data member instead of const char*
2) As a consequence of (1), string_view will be impossible to use with
const character data, whether its from static memory, stack memory,
std::string, or otherwise.
//This is not possible. Where do we allocate the byte for the nul?
const char name[] = {'a','b','c','d'};
string_view s{name, sizeof(name); }

3) it will require either memory allocations to allocate a buffer with one
more character with the null, or restrict the construction interface to
force the user to always pass a buffer with enough space for the null byte.
4) In order to be able to program with this, we should guarantee either
always terminated or never required to be terminated. The following
function would be an abomination.
//This string_view must be null terminated! I hope you read this comment!q
void foo(string_view sv);
5) string_view is supposed to be just what it name implies, a view into a
string. If someone has a string_view to your string, as soon as they do
something as innocent as .c_str(), your string gets mutated with a null
byte. This will lead to a lot of nasty bugs and make programs difficult to
reason about.

If you want a string_view with null termination guarantees, the *only*
correct way to do it is to make a new type that enforces this invariant.
Now my foo function can be written the right way. Notice there are no
comments.
void foo(zstring_view sv);

I know by the function signature what guarantees I get. Most importantly,
the compiler asserts the null termination invariants by the restricted
interface of 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1286_8430705.1380988470921
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There are many problems with null termination:<div>1) subs=
tr, splicing, and any other size mutating operations requires mutability be=
cause it has write a null byte. string_view must then take char* arguments =
in its constructors instead of const char*. It must also have a char* data =
member instead of const char*</div><div>2) As a consequence of (1), string_=
view will be impossible to use with const character data, whether its from =
static memory, stack memory, std::string, or otherwise.</div><div><div>//Th=
is is not possible. Where do we allocate the byte for the nul?</div><div>co=
nst char name[] =3D {'a','b','c','d'};</div><div>string_view s{name, sizeof=
(name); }</div></div><div><br></div><div>3) it will require either memory a=
llocations to allocate a buffer with one more character with the null, or r=
estrict the construction interface to force the user to always pass a buffe=
r with enough space for the null byte.</div><div>4) In order to be able to =
program with this, we should guarantee either always terminated or never re=
quired to be terminated. The following function would be an abomination.</d=
iv><div>//This string_view must be null terminated! I hope you read this co=
mment!q</div><div>void foo(string_view sv);</div><div>5) string_view is sup=
posed to be just what it name implies, a view into a string. If someone has=
 a string_view to your string, as soon as they do something as innocent as =
..c_str(), your string gets mutated with a null byte. This will lead to a lo=
t of nasty bugs and make programs difficult to reason about.</div><div><br>=
</div><div>If you want a string_view with null termination guarantees, the =
*only* correct way to do it is to make a new type that enforces this invari=
ant.</div><div>Now my foo function can be written the right way. Notice the=
re are no comments.</div><div>void foo(zstring_view sv);</div><div><br></di=
v><div>I know by the function signature what guarantees I get. Most importa=
ntly, the compiler asserts the null termination invariants by the restricte=
d interface of zstring_view.</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1286_8430705.1380988470921--

.

------=_Part_1598_7783308.1380989082746
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, October 5, 2013 11:08:51 AM UTC-4, Olaf van der Spek wrote:
>
> On Friday, October 4, 2013 7:43:19 PM UTC+2, Billy O'Neal wrote:
>
>> Yes, according to the proposal. However, several "string_view ish"
>> implementations out there do not allow chopping off the end, do require
>> null, and as a result can cheaply give you null termination. This is
>> nothing more than a design tradeoff. The proposal has chosen to allow
>> chopping the end off at the expense of not being able to provide cheap
>> backcompat with C APIs.
>>
>> Kinda true, an additional zstring_view would still be possible if it's a
> frequent use case.
>

Its certainly not a bad idea. If you need to do a lot of efficient string
parsing and then at the end pass it to legacy C function,
having null termination matters. C null terminated strings are NOT going to
go away for a very long long time if ever.
And then you can even have a mutable_zstring_view which lets you do
chopping operations and fixes up the null bytes for you.
Of course now we have 6 string types.
const char*
string
string_view
mutable_string_view
zstring_view
mutable_zstring_view

What would the world look like with all of these? While I certainly think
every single one of these has valid uses cases
(except probably const char*, that could likely become legacy and not used
for new interfaces) its a lot of
different strings to have to learn how to use.

On the other hand efficient text parsing is one of the biggest and most
important tasks for many
software applications over almost every domain. Its also often a
bottleneck. The C++ standard should provide all of the primitives to do
this effectively,



--

---
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_1598_7783308.1380989082746
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, October 5, 2013 11:08:51 AM UTC-4, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Friday, October 4, 2013 7:43:19 PM UTC+2, Billy O'Neal wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Yes, according t=
o the proposal. However, several "string_view ish" implementations out ther=
e do not allow chopping off the end, do require null, and as a result can c=
heaply give you null termination. This is nothing more than a design tradeo=
ff. The proposal has chosen to allow chopping the end off at the expense of=
 not being able to provide cheap backcompat with C APIs.</div>

<div><br></div></blockquote><div>Kinda true, an additional zstring_view wou=
ld still be possible if it's a frequent use case.&nbsp;</div></div></blockq=
uote><div><br></div><div>Its certainly not a bad idea. If you need to do a =
lot of efficient string parsing and then at the end pass it to legacy C fun=
ction,</div><div>having null termination matters. C null terminated strings=
 are NOT going to go away for a very long long time if ever.</div><div>And =
then you can even have a mutable_zstring_view which lets you do chopping op=
erations and fixes up the null bytes for you.</div><div>Of course now we ha=
ve 6 string types.</div><div>const char*&nbsp;</div><div>string&nbsp;</div>=
<div>string_view&nbsp;</div><div>mutable_string_view</div><div>zstring_view=
</div><div>mutable_zstring_view</div><div><br></div><div>What would the wor=
ld look like with all of these? While I certainly think every single one of=
 these has valid uses cases&nbsp;</div><div>(except probably const char*, t=
hat could likely become legacy and not used for new interfaces) its a lot o=
f&nbsp;</div><div>different strings to have to learn how to use.&nbsp;</div=
><div><br></div><div>On the other hand efficient text parsing is one of the=
 biggest and most important tasks for many&nbsp;</div><div>software applica=
tions over almost every domain. Its also often a&nbsp;</div><div>bottleneck=
.. The C++ standard should provide all of the primitives to do this effectiv=
ely,</div><div><br></div><div><br></div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1598_7783308.1380989082746--

.

--047d7b624d345e509104e8021fa3
Content-Type: text/plain; charset=ISO-8859-1

On 5 October 2013 11:04, <fmatthew5876@gmail.com> wrote:

>
>
> On Saturday, October 5, 2013 11:08:51 AM UTC-4, Olaf van der Spek wrote:
>>
>> On Friday, October 4, 2013 7:43:19 PM UTC+2, Billy O'Neal wrote:
>>
>>> Yes, according to the proposal. However, several "string_view ish"
>>> implementations out there do not allow chopping off the end, do require
>>> null, and as a result can cheaply give you null termination. This is
>>> nothing more than a design tradeoff. The proposal has chosen to allow
>>> chopping the end off at the expense of not being able to provide cheap
>>> backcompat with C APIs.
>>>
>>> Kinda true, an additional zstring_view would still be possible if it's a
>> frequent use case.
>>
>
> Its certainly not a bad idea.
>

Yes, it is.

Again, what does it buy over using const char*?
--
 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/.

--047d7b624d345e509104e8021fa3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 5 October 2013 11:04,  <span dir=3D"ltr">&lt;<a href=3D=
"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@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 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"im"><br><br>On Saturday, October 5, 2013 11:=
08:51 AM UTC-4, Olaf van der Spek wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">

<div dir=3D"ltr">On Friday, October 4, 2013 7:43:19 PM UTC+2, Billy O&#39;N=
eal wrote:<br><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">Yes,=
 according to the proposal. However, several &quot;string_view ish&quot; im=
plementations out there do not allow chopping off the end, do require null,=
 and as a result can cheaply give you null termination. This is nothing mor=
e than a design tradeoff. The proposal has chosen to allow chopping the end=
 off at the expense of not being able to provide cheap backcompat with C AP=
Is.</div>



<div><br></div></blockquote><div>Kinda true, an additional zstring_view wou=
ld still be possible if it&#39;s a frequent use case.=A0</div></div></block=
quote><div><br></div></div><div>Its certainly not a bad idea.</div></div>

</blockquote><div><br></div><div>Yes, it is.</div><div><br></div><div>Again=
, what does it buy over using const char*?</div></div>-- <br>=A0Nevin &quot=
;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" ta=
rget=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b624d345e509104e8021fa3--

.

------=_Part_1676_6246977.1380996393186
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, October 5, 2013 1:54:40 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 5 October 2013 11:04, <fmatth...@gmail.com <javascript:>> wrote:
>
>>
>>
>> On Saturday, October 5, 2013 11:08:51 AM UTC-4, Olaf van der Spek wrote:
>>>
>>> On Friday, October 4, 2013 7:43:19 PM UTC+2, Billy O'Neal wrote:
>>>
>>>> Yes, according to the proposal. However, several "string_view ish"
>>>> implementations out there do not allow chopping off the end, do require
>>>> null, and as a result can cheaply give you null termination. This is
>>>> nothing more than a design tradeoff. The proposal has chosen to allow
>>>> chopping the end off at the expense of not being able to provide cheap
>>>> backcompat with C APIs.
>>>>
>>>> Kinda true, an additional zstring_view would still be possible if it's
>>> a frequent use case.
>>>
>>
>> Its certainly not a bad idea.
>>
>
> Yes, it is.
>
> Again, what does it buy over using const char*?
>

Two things:
1) Its not a pointer, so no confusion with pointer types when you want a
null terminated string. (Consider std::unordered_map<const char*, T>).
2) Its caches the value of strlen(), avoiding wasted strlen() calls at each
layer of the call stack. Yes you can always pass a pointer and length as 2
arguments, but it's better to fuse them together into 1 type  and have the
compiler enforce the invariants, namely this:
zstring_view zs;
assert(zs.c_str()[zs.length()] == '\0');


--

---
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_1676_6246977.1380996393186
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, October 5, 2013 1:54:40 PM UTC-4, Nev=
in ":-)" Liber 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">On 5 October 2013 11:04,  <span dir=3D"ltr">&lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"---smK7Z8PMJ">fmatth...@gm=
ail.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">

<div dir=3D"ltr"><div><br><br>On Saturday, October 5, 2013 11:08:51 AM UTC-=
4, Olaf van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">On Friday, October 4, 2013 7:43:19 PM UTC+2, Billy O'Neal =
wrote:<br><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">Yes, acc=
ording to the proposal. However, several "string_view ish" implementations =
out there do not allow chopping off the end, do require null, and as a resu=
lt can cheaply give you null termination. This is nothing more than a desig=
n tradeoff. The proposal has chosen to allow chopping the end off at the ex=
pense of not being able to provide cheap backcompat with C APIs.</div>



<div><br></div></blockquote><div>Kinda true, an additional zstring_view wou=
ld still be possible if it's a frequent use case.&nbsp;</div></div></blockq=
uote><div><br></div></div><div>Its certainly not a bad idea.</div></div>

</blockquote><div><br></div><div>Yes, it is.</div><div><br></div><div>Again=
, what does it buy over using const char*?</div></div></div></div></blockqu=
ote><div><br></div><div>Two things:</div><div>1) Its not a pointer, so no c=
onfusion with pointer types when you want a null terminated string. (Consid=
er std::unordered_map&lt;const char*, T&gt;).</div><div>2) Its caches the v=
alue of strlen(), avoiding wasted strlen() calls at each layer of the call =
stack. Yes you can always pass a pointer and length as 2 arguments, but it'=
s better to fuse them together into 1 type &nbsp;and have the compiler enfo=
rce the invariants, namely this:</div><div>zstring_view zs;</div><div>asser=
t(zs.c_str()[zs.length()] =3D=3D '\0');</div><div>&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1676_6246977.1380996393186--

.

------=_Part_502_14593759.1381487733799
Content-Type: text/plain; charset=ISO-8859-1

What a pointless thread. Thread creator doesn't seem to have any experience
with text processing at all, but supposedly string_view is broken because
it doesn't have the semantics he expects.

I suggest you first get some experience, you are just wrong and ignorant.

--

---
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_502_14593759.1381487733799
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What a pointless thread. Thread creator doesn't seem to ha=
ve any experience with text processing at all, but supposedly string_view i=
s broken because it doesn't have the semantics he expects.<br><br>I suggest=
 you first get some experience, you are just wrong and ignorant.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_502_14593759.1381487733799--

.

On Fri, Oct 11, 2013 at 3:35 AM,  <stackmachine@hotmail.com> wrote:
> What a pointless thread. Thread creator doesn't seem to have any experience
> with text processing at all, but supposedly string_view is broken because it
> doesn't have the semantics he expects.
>
> I suggest you first get some experience, you are just wrong and ignorant.

Please be a more polite here. The thread isn't pointless: ownership
issues are important and difficult, and string_view does put that
burden on the caller. I agree with others here that the risk is worth
the benefits, but that doesn't make it wrong to ask explicitly what
the benefits are.

--

---
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_847_8739000.1381520654889
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

=20

Thanks for the advice. I happen to know a few things about parsers. I know=
=20
that you do not always have access to the full string, or can=92t wait to=
=20
have the full data to start parsing, that you might have to work with=20
linked list of string as if they were a single string. I also know that=20
once you have parsed you data, you have to consume them, maybe pass them to=
=20
another thread and that, sometimes, the result is not a string but an int,=
=20
a double, or a date=85 I also know that you can use flyweights to avoid (lo=
ts=20
of) copy while reading an XML file.

I know how to use a string view. I already did, the implementation was=20
simple, all the complexity about the ownership was nicely encapsulated in=
=20
the outer class and I had no refactoring to do when I had to add extra=20
data, such as a token, and I was able to add all the helpers I needed=20
(starts_with, substring_before, substring_after, =85) or even null semantic=
s,=20
because it was my class.

I simply happen to think that, when you standardize a class like, you will=
=20
start to see it a lot in libraries or third party code. Because of that, it=
=20
might not always be simple to track the =93owner=94 or to know for sure wha=
t=20
operations will invalidate your views.=20

Look at the following code.

#include <algorithm>

#include <iostream>

#include <regex>

#include <string>

#include <vector>

#include <boost/utility/string_ref.hpp>

=20

typedef boost::string_ref string_view;

=20

using namespace std;

=20

string_view parse_name(const string& name);

=20

struct Person {

       string name;

       string_view lastname;

=20

       Person(const string& n) : name(n), lastname(parse_name(name)) {}

       Person(Person&& p) : name(move(p.name)), lastname(move(p.lastname))=
=20
{}

=20

       friend bool operator <(const Person& x, const Person& y) {

             return x.lastname < y.lastname;

       }

};

=20

int main(int argc, char* argv[])

{

       string line;

       vector<Person> persons;

=20

       while(cin) {

             getline(cin, line);

             if(line.empty())

                    break;

             persons.emplace_back(line);

       }

=20

       stable_sort(persons.begin(), persons.end());

=20

       char letter =3D '\0';

       for(auto it =3D persons.cbegin(), end =3D persons.cend(); it !=3D en=
d;=20
++it) {

             if(it->lastname[0] !=3D letter) {

                    letter =3D it->lastname[0];

                    cout << letter << endl;

             }

             cout << "  " << it->name << endl;

       }

=20

       return 0;

}

It looks pretty simple and straightforward yet it does not work. So yes, it=
=20
worries me enough to think about it, ask about it, and look for good=20
practice, advices and alternatives. Others think the risk is worth the=20
benefits. I completly respect that.

So yes, you are right, I should get more experience, that's exactly what I=
=20
am doing right here, right now. I haven=92t been seriously coding in C++ fo=
r=20
the past ten years - you do not have ownership issues when passing around=
=20
string in C# - and I am learning this language anew, on my free time. I=20
definitively lack confidence, that=92s why I am glad when the design of the=
=20
classes, or the compiler, help me.

And that=92s also why I am grateful to all the people who took the time to=
=20
reply to me.

Best regards,

Vincent JACQUET


On Friday, October 11, 2013 12:35:33 PM UTC+2, stackm...@hotmail.com wrote:
>
> What a pointless thread. Thread creator doesn't seem to have any=20
> experience with text processing at all, but supposedly string_view is=20
> broken because it doesn't have the semantics he expects.
>
> I suggest you first get some experience, you are just wrong and ignorant.
>

--=20

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

------=_Part_847_8739000.1381520654889
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:DoNotShowComments/>
  <w:HyphenationZone>21</w:HyphenationZone>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>FR</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:DontVertAlignCellWithSp/>
   <w:DontBreakConstrainedForcedTables/>
   <w:DontVertAlignInTxbx/>
   <w:Word11KerningPairs/>
   <w:CachedColBalance/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
  <m:mathPr>
   <m:mathFont m:val=3D"Cambria Math"/>
   <m:brkBin m:val=3D"before"/>
   <m:brkBinSub m:val=3D"&#45;-"/>
   <m:smallFrac m:val=3D"off"/>
   <m:dispDef/>
   <m:lMargin m:val=3D"0"/>
   <m:rMargin m:val=3D"0"/>
   <m:defJc m:val=3D"centerGroup"/>
   <m:wrapIndent m:val=3D"1440"/>
   <m:intLim m:val=3D"subSup"/>
   <m:naryLim m:val=3D"undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]-->

<p class=3D"MsoNormal"><span style=3D"mso-ansi-language:EN-US" lang=3D"EN-U=
S">Thanks for
the advice. I happen to know a few things about parsers. I know that you do=
 not
always have access to the full string, or can=92t wait to have the full dat=
a to
start parsing, that you might have to work with linked list of
string as if they were a single string. I also know that once you have pars=
ed
you data, you have to consume them, maybe pass them to another thread and t=
hat,
sometimes, the result is not a string but an int, a double, or a date=85 I =
also
know that you can use flyweights to avoid (lots of) copy while reading an X=
ML
file.</span></p>

<p class=3D"MsoNormal"><span style=3D"mso-ansi-language:EN-US" lang=3D"EN-U=
S">I know how
to use a string view. I already did, the implementation was simple, all the=
 complexity
about the ownership was nicely encapsulated in the outer class and I had no
refactoring to do when I had to add extra data, such as a token, and I was =
able
to add all the helpers I needed (starts_with, substring_before, substring_a=
fter,
=85) or even null semantics, because it was my class.</span></p>

<p class=3D"MsoNormal"><span style=3D"mso-ansi-language:EN-US" lang=3D"EN-U=
S">I simply
happen to think that, when you standardize a class like, you will start to =
see
it a lot in libraries or third party code. Because of that, it might not al=
ways
be simple to track the =93owner=94 or to know for sure what operations will
invalidate your views. </span></p>

<p class=3D"MsoNormal"><span style=3D"mso-ansi-language:EN-US" lang=3D"EN-U=
S">Look at the
following code.</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">#include</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#A31515;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&lt;algorithm&g=
t;</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;ba=
ckground:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"></span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">#include</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#A31515;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&lt;iostream&gt=
;</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;bac=
kground:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"></span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">#include</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#A31515;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&lt;regex&gt;</=
span><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgr=
ound:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"></span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">#include</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#A31515;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&lt;string&gt;<=
/span><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backg=
round:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"></span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">#include</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#A31515;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&lt;vector&gt;<=
/span><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backg=
round:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"></span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">#include</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#A31515;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&lt;boost/utili=
ty/string_ref.hpp&gt;</span><span style=3D"font-size:9.5pt;font-family:Cons=
olas;color:black;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"></span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">typedef</span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:w=
hite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> boost::string_=
ref string_view;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">using</span><sp=
an style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whi=
te;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">namespace</span=
><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background=
:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> std;</span></p=
>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">string_view par=
se_name(</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:bl=
ue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">const</sp=
an><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgrou=
nd:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> string&a=
mp; name);</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">struct</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> Person {</span=
></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>string
name;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>string_view
lastname;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Person(</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">const</sp=
an><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgrou=
nd:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> string&a=
mp; n) : name(n),
lastname(parse_name(name)) {}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Person(Person&=
amp;&amp;
p) : name(move(p.name)), lastname(move(p.lastname)) {}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">friend</s=
pan><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgro=
und:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">bool</span><spa=
n style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whit=
e;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">operator</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> &lt;(</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:whi=
te;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">const</span><sp=
an style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whi=
te;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> Person&amp; x,=
 </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;back=
ground:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">const</sp=
an><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgrou=
nd:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> Person&a=
mp; y) {</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span></span><span style=3D"font-size:9.5pt;font-family:Con=
solas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">return</s=
pan><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgro=
und:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> x.lastna=
me &lt; y.lastname;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">};</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">int</span><span=
 style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> main(</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:whi=
te;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">int</span><span=
 style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> argc, </span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">char</span><spa=
n style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whit=
e;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">* argv[])</span=
></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">{</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>string
line;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>vector&lt;Pers=
on&gt;
persons;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">while</sp=
an><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgrou=
nd:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">(cin) {</=
span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span>getline(cin,
line);</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span></span><span style=3D"font-size:9.5pt;font-family:Con=
solas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">if</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">(line.empty())<=
/span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><spa=
n style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">break</sp=
an><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgrou=
nd:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">;</span><=
/p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span>persons.emplace_back(line);</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>stable_sort(pe=
rsons.begin(),
persons.end());</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">char</spa=
n><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgroun=
d:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> letter =3D </s=
pan><span style=3D"font-size:9.5pt;font-family:Consolas;color:#A31515;backg=
round:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">'\0'</span><spa=
n style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whit=
e;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">for</span=
><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background=
:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">(</span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">auto</span><spa=
n style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whit=
e;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> it =3D persons=
..cbegin(), end =3D
persons.cend(); it !=3D end; ++it) {</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span></span><span style=3D"font-size:9.5pt;font-family:Con=
solas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">if</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">(it-&gt;lastnam=
e[0] !=3D letter) {</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>letter
=3D it-&gt;lastname[0];</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>cout
&lt;&lt; letter &lt;&lt; endl;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span>}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span>cout
&lt;&lt; </span><span style=3D"font-size:9.5pt;font-family:Consolas;
color:#A31515;background:white;mso-highlight:white;mso-ansi-language:EN-US"=
 lang=3D"EN-US">"<span style=3D"mso-spacerun:yes">&nbsp; </span>"</span><sp=
an style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whi=
te;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> &lt;&lt; it-&g=
t;name &lt;&lt;
endl;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white">}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:
9.5pt;font-family:Consolas;color:black;background:white;mso-highlight:white=
">&nbsp;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:
9.5pt;font-family:Consolas;color:black;background:white;mso-highlight:white=
"><span style=3D"mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </sp=
an></span><span style=3D"font-size:9.5pt;
font-family:Consolas;color:blue;background:white;mso-highlight:white">retur=
n</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;bac=
kground:white;
mso-highlight:white"> 0;</span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:9.5pt;line-height:115%;font=
-family:
Consolas;color:black;background:white;mso-highlight:white">}</span><span st=
yle=3D"font-size:9.5pt;line-height:115%;font-family:Consolas;color:black"><=
/span></p>

<p class=3D"MsoNormal"><span style=3D"mso-ansi-language:EN-US" lang=3D"EN-U=
S">It looks
pretty simple and straightforward yet it does not work. So yes, it worries =
me
enough to think about it, ask about it, and look for good practice, advices=
 and
alternatives. Others think the risk is worth the benefits. I completly resp=
ect that.<br></span></p>

<p class=3D"MsoNormal"><span style=3D"mso-ansi-language:EN-US" lang=3D"EN-U=
S">So yes, you are
right, I should get more experience, that's exactly what I am doing right h=
ere, right now. I haven=92t been seriously coding in C++ for
the past ten years - you do not have ownership issues when passing around
string in C# - and I am learning this language anew, on my free time. I
definitively lack confidence, that=92s why I am glad when the design of the
classes, or the compiler, help me.</span></p>

<p class=3D"MsoNormal"><span style=3D"mso-ansi-language:EN-US" lang=3D"EN-U=
S">And that=92s also
why I am grateful to all the people who took the time to reply to me.</span=
></p>



<p class=3D"MsoNormal"><span style=3D"mso-ansi-language:EN-US" lang=3D"EN-U=
S">Best
regards,</span></p>

<p class=3D"MsoNormal"><span style=3D"mso-ansi-language:EN-US" lang=3D"EN-U=
S">Vincent
JACQUET</span></p>

<!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true"
  DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99"
  LatentStyleCount=3D"267">
  <w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" Name=3D=
"caption"/>
  <w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default Paragraph=
 Font"/>
  <w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
  <w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
  <w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" Name=3D"Placeho=
lder Text"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" Name=3D"Revisio=
n"/>
  <w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
  <w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"37" Name=3D"Bibliography"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" Name=3D=
"TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]--><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
 {mso-style-name:"Tableau Normal";
 mso-tstyle-rowband-size:0;
 mso-tstyle-colband-size:0;
 mso-style-noshow:yes;
 mso-style-priority:99;
 mso-style-qformat:yes;
 mso-style-parent:"";
 mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
 mso-para-margin-top:0cm;
 mso-para-margin-right:0cm;
 mso-para-margin-bottom:10.0pt;
 mso-para-margin-left:0cm;
 line-height:115%;
 mso-pagination:widow-orphan;
 font-size:11.0pt;
 font-family:"Calibri","sans-serif";
 mso-ascii-font-family:Calibri;
 mso-ascii-theme-font:minor-latin;
 mso-fareast-font-family:"Times New Roman";
 mso-fareast-theme-font:minor-fareast;
 mso-hansi-font-family:Calibri;
 mso-hansi-theme-font:minor-latin;}
</style>
<![endif]--><br><br>On Friday, October 11, 2013 12:35:33 PM UTC+2, stackm..=
..@hotmail.com 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">What a pointless thread. Thread creator doesn't seem to have any e=
xperience with text processing at all, but supposedly string_view is broken=
 because it doesn't have the semantics he expects.<br><br>I suggest you fir=
st get some experience, you are just wrong and ignorant.<br></div></blockqu=
ote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_847_8739000.1381520654889--

.

--20cf307d064a1a4c4504e87e9e66
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 11, 2013 at 12:44 PM, Vincent Jacquet <vjacquet@flowgroup.fr>wr=
ote:

> Thanks for the advice. I happen to know a few things about parsers. I kno=
w
> that you do not always have access to the full string, or can=92t wait to
> have the full data to start parsing, that you might have to work with
> linked list of string as if they were a single string. I also know that
> once you have parsed you data, you have to consume them, maybe pass them =
to
> another thread and that, sometimes, the result is not a string but an int=
,
> a double, or a date=85 I also know that you can use flyweights to avoid (=
lots
> of) copy while reading an XML file.
>
> I know how to use a string view. I already did, the implementation was
> simple, all the complexity about the ownership was nicely encapsulated in
> the outer class and I had no refactoring to do when I had to add extra
> data, such as a token, and I was able to add all the helpers I needed
> (starts_with, substring_before, substring_after, =85) or even null semant=
ics,
> because it was my class.
>
> I simply happen to think that, when you standardize a class like, you wil=
l
> start to see it a lot in libraries or third party code. Because of that, =
it
> might not always be simple to track the =93owner=94 or to know for sure w=
hat
> operations will invalidate your views.
>
> Look at the following code.
>
> #include <algorithm>
>
> #include <iostream>
>
> #include <regex>
>
> #include <string>
>
> #include <vector>
>
> #include <boost/utility/string_ref.hpp>
>
>
>
> typedef boost::string_ref string_view;
>
>
>
> using namespace std;
>
>
>
> string_view parse_name(const string& name);
>
>
>
> struct Person {
>
>        string name;
>
>        string_view lastname;
>

For me, this immediately triggers alarm bells: string_view is a
reference-like type, and reference members are often dangerous, especially
if they are references to other class members...

       Person(const string& n) : name(n), lastname(parse_name(name)) {}
>

.... which this one is.

       Person(Person&& p) : name(move(p.name)), lastname(move(p.lastname))
> {}
>
>
>
>        friend bool operator <(const Person& x, const Person& y) {
>
>              return x.lastname < y.lastname;
>
>        }
>

This class does not follow the rule of zero, so its copy operations should
be subject to scrutiny. It does not follow the rule of five, either, which
suggests its implicit assignment operator may be incorrect, which is indeed
the case.


> };
>
>
>
> int main(int argc, char* argv[])
>
> {
>
>        string line;
>
>        vector<Person> persons;
>
>
>
>        while(cin) {
>
>              getline(cin, line);
>
>              if(line.empty())
>
>                     break;
>
>              persons.emplace_back(line);
>
>        }
>
>
>
>        stable_sort(persons.begin(), persons.end());
>

This may odr-use the copy assignment operator of Person. Such use is
deprecated, because Person has a user-declared copy constructor. Modern
compilers are likely to start warning about this soon.

       char letter =3D '\0';
>
>        for(auto it =3D persons.cbegin(), end =3D persons.cend(); it !=3D =
end;
> ++it) {
>
>              if(it->lastname[0] !=3D letter) {
>
>                     letter =3D it->lastname[0];
>
>                     cout << letter << endl;
>
>              }
>
>              cout << "  " << it->name << endl;
>
>        }
>
>
>
>        return 0;
>
> }
>
> It looks pretty simple and straightforward yet it does not work. So yes,
> it worries me enough to think about it, ask about it, and look for good
> practice, advices and alternatives. Others think the risk is worth the
> benefits. I completly respect that.
>
> So yes, you are right, I should get more experience, that's exactly what =
I
> am doing right here, right now. I haven=92t been seriously coding in C++ =
for
> the past ten years - you do not have ownership issues when passing around
> string in C# - and I am learning this language anew, on my free time. I
> definitively lack confidence, that=92s why I am glad when the design of t=
he
> classes, or the compiler, help me.
>

For the above case, you should gain more assistance in future: compilers
will implement the deprecation warning pointing out that your class
"Person" is incorrect. That doesn't entirely address the problem, though:
there are still risks with idiomatic use of string_view and similar types,
and we need to be aware that these are reference-like types in order to use
them safely. It may not be obvious to a novice that this code is buggy:

  string_view foo() {
    string s;
    // ...
    return s;
  }

.... and this is currently a worse problem than if 'foo' returns 'string&',
since compilers don't catch this bug today.


> And that=92s also why I am grateful to all the people who took the time t=
o
> reply to me.
>
> Best regards,
>
> Vincent JACQUET
>
>
> On Friday, October 11, 2013 12:35:33 PM UTC+2, stackm...@hotmail.comwrote=
:
>>
>> What a pointless thread. Thread creator doesn't seem to have any
>> experience with text processing at all, but supposedly string_view is
>> broken because it doesn't have the semantics he expects.
>>
>> I suggest you first get some experience, you are just wrong and ignorant=
..
>>
>  --
>
> ---
> 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/.
>

--=20

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

--20cf307d064a1a4c4504e87e9e66
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Oct 11, 2013 at 12:44 PM, Vincent Jacquet <span di=
r=3D"ltr">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vj=
acquet@flowgroup.fr</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">

<p class=3D"MsoNormal"><span lang=3D"EN-US">Thanks for
the advice. I happen to know a few things about parsers. I know that you do=
 not
always have access to the full string, or can=92t wait to have the full dat=
a to
start parsing, that you might have to work with linked list of
string as if they were a single string. I also know that once you have pars=
ed
you data, you have to consume them, maybe pass them to another thread and t=
hat,
sometimes, the result is not a string but an int, a double, or a date=85 I =
also
know that you can use flyweights to avoid (lots of) copy while reading an X=
ML
file.</span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US">I know how
to use a string view. I already did, the implementation was simple, all the=
 complexity
about the ownership was nicely encapsulated in the outer class and I had no
refactoring to do when I had to add extra data, such as a token, and I was =
able
to add all the helpers I needed (starts_with, substring_before, substring_a=
fter,
=85) or even null semantics, because it was my class.</span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US">I simply
happen to think that, when you standardize a class like, you will start to =
see
it a lot in libraries or third party code. Because of that, it might not al=
ways
be simple to track the =93owner=94 or to know for sure what operations will
invalidate your views. </span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US">Look at the
following code.</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">#include</span><s=
pan style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D=
"EN-US"> </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:#=
a31515;background:white" lang=3D"EN-US">&lt;algorithm&gt;</span><span style=
=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"><=
/span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">#include</span><s=
pan style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D=
"EN-US"> </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:#=
a31515;background:white" lang=3D"EN-US">&lt;iostream&gt;</span><span style=
=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"><=
/span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">#include</span><s=
pan style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D=
"EN-US"> </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:#=
a31515;background:white" lang=3D"EN-US">&lt;regex&gt;</span><span style=3D"=
background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"></spa=
n></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">#include</span><s=
pan style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D=
"EN-US"> </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:#=
a31515;background:white" lang=3D"EN-US">&lt;string&gt;</span><span style=3D=
"background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"></sp=
an></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">#include</span><s=
pan style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D=
"EN-US"> </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:#=
a31515;background:white" lang=3D"EN-US">&lt;vector&gt;</span><span style=3D=
"background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"></sp=
an></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">#include</span><s=
pan style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D=
"EN-US"> </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:#=
a31515;background:white" lang=3D"EN-US">&lt;boost/utility/string_ref.hpp&gt=
;</span><span style=3D"background:white;font-size:9.5pt;font-family:Consola=
s" lang=3D"EN-US"></span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">=A0</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">typedef</span><sp=
an style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D"=
EN-US"> boost::string_ref string_view;</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">=A0</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">using</span><span=
 style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN=
-US"> </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:blue=
;background:white" lang=3D"EN-US">namespace</span><span style=3D"background=
:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"> std;</span></p=
>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">=A0</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">string_view parse_name(</spa=
n><span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background=
:white" lang=3D"EN-US">const</span><span style=3D"background:white;font-siz=
e:9.5pt;font-family:Consolas" lang=3D"EN-US"> string&amp; name);</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">=A0</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">struct</span><spa=
n style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D"E=
N-US"> Person {</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan>string
name;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan>string_view
lastname;</span></p></div></blockquote><div><br></div><div>For me, this imm=
ediately triggers alarm bells: string_view is a reference-like type, and re=
ference members are often dangerous, especially if they are references to o=
ther class members...</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan>Person(</span><span style=3D"font-size:9.5pt;font-family:Consolas;color=
:blue;background:white" lang=3D"EN-US">const</span><span style=3D"backgroun=
d:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"> string&amp; n=
) : name(n),
lastname(parse_name(name)) {}</span></p></div></blockquote><div><br></div><=
div>... which this one is.</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<div dir=3D"ltr">

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan>Person(Person&amp;&amp;
p) : name(move(<a href=3D"http://p.name" target=3D"_blank">p.name</a>)), la=
stname(move(p.lastname)) {}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">=A0</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan></span><span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;b=
ackground:white" lang=3D"EN-US">friend</span><span style=3D"background:whit=
e;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"> </span><span style=
=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:white" lang=
=3D"EN-US">bool</span><span style=3D"background:white;font-size:9.5pt;font-=
family:Consolas" lang=3D"EN-US"> </span><span style=3D"font-size:9.5pt;font=
-family:Consolas;color:blue;background:white" lang=3D"EN-US">operator</span=
><span style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=
=3D"EN-US"> &lt;(</span><span style=3D"font-size:9.5pt;font-family:Consolas=
;color:blue;background:white" lang=3D"EN-US">const</span><span style=3D"bac=
kground:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"> Person&=
amp; x, </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:bl=
ue;background:white" lang=3D"EN-US">const</span><span style=3D"background:w=
hite;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"> Person&amp; y) {=
</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 </span></span><span style=3D"font-size:9.5pt;font-family:Co=
nsolas;color:blue;background:white" lang=3D"EN-US">return</span><span style=
=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"> =
x.lastname &lt; y.lastname;</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan>}</span></p>
</div></blockquote><div><br></div><div>This class does not follow the rule =
of zero, so its copy operations should be subject to scrutiny. It does not =
follow the rule of five, either, which suggests its implicit assignment ope=
rator may be incorrect, which is indeed the case.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">};</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">=A0</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"font-size:9.5pt;font-fa=
mily:Consolas;color:blue;background:white" lang=3D"EN-US">int</span><span s=
tyle=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-U=
S"> main(</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:b=
lue;background:white" lang=3D"EN-US">int</span><span style=3D"background:wh=
ite;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"> argc, </span><spa=
n style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:white=
" lang=3D"EN-US">char</span><span style=3D"background:white;font-size:9.5pt=
;font-family:Consolas" lang=3D"EN-US">* argv[])</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">{</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan>string
line;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan>vector&lt;Person&gt;
persons;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">=A0</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan></span><span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;b=
ackground:white" lang=3D"EN-US">while</span><span style=3D"background:white=
;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US">(cin) {</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 </span>getline(cin,
line);</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 </span></span><span style=3D"font-size:9.5pt;font-family:Co=
nsolas;color:blue;background:white" lang=3D"EN-US">if</span><span style=3D"=
background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US">(line=
..empty())</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 </span></span><span style=3D"font-size=
:9.5pt;font-family:Consolas;color:blue;background:white" lang=3D"EN-US">bre=
ak</span><span style=3D"background:white;font-size:9.5pt;font-family:Consol=
as" lang=3D"EN-US">;</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 </span>persons.emplace_back(line);</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan>}</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US">=A0</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan>stable_sort(persons.begin(),
persons.end());</span></p></div></blockquote><div><br></div><div>This may o=
dr-use the copy assignment operator of Person. Such use is deprecated, beca=
use Person has a user-declared copy constructor. Modern compilers are likel=
y to start warning about this soon.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan></span><span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;b=
ackground:white" lang=3D"EN-US">char</span><span style=3D"background:white;=
font-size:9.5pt;font-family:Consolas" lang=3D"EN-US"> letter =3D </span><sp=
an style=3D"font-size:9.5pt;font-family:Consolas;color:#a31515;background:w=
hite" lang=3D"EN-US">&#39;\0&#39;</span><span style=3D"background:white;fon=
t-size:9.5pt;font-family:Consolas" lang=3D"EN-US">;</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan></span><span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;b=
ackground:white" lang=3D"EN-US">for</span><span style=3D"background:white;f=
ont-size:9.5pt;font-family:Consolas" lang=3D"EN-US">(</span><span style=3D"=
font-size:9.5pt;font-family:Consolas;color:blue;background:white" lang=3D"E=
N-US">auto</span><span style=3D"background:white;font-size:9.5pt;font-famil=
y:Consolas" lang=3D"EN-US"> it =3D persons.cbegin(), end =3D
persons.cend(); it !=3D end; ++it) {</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 </span></span><span style=3D"font-size:9.5pt;font-family:Co=
nsolas;color:blue;background:white" lang=3D"EN-US">if</span><span style=3D"=
background:white;font-size:9.5pt;font-family:Consolas" lang=3D"EN-US">(it-&=
gt;lastname[0] !=3D letter) {</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 </span>letter
=3D it-&gt;lastname[0];</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 </span>cout
&lt;&lt; letter &lt;&lt; endl;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 </span>}</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 </span>cout
&lt;&lt; </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:#=
a31515;background:white" lang=3D"EN-US">&quot;<span>=A0 </span>&quot;</span=
><span style=3D"background:white;font-size:9.5pt;font-family:Consolas" lang=
=3D"EN-US"> &lt;&lt; it-&gt;name &lt;&lt;
endl;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas" lang=3D"EN-US"><span>=A0=A0=A0=A0=A0=A0 </s=
pan></span><span style=3D"background:white;font-size:9.5pt;font-family:Cons=
olas">}</span></p>


<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas">=A0</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:normal;text-autospace:none"><span style=3D"background:white;font-s=
ize:9.5pt;font-family:Consolas"><span>=A0=A0=A0=A0=A0=A0 </span></span><spa=
n style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:white=
">return</span><span style=3D"background:white;font-size:9.5pt;font-family:=
Consolas"> 0;</span></p>


<p class=3D"MsoNormal"><span style=3D"line-height:115%;background:white;fon=
t-size:9.5pt;font-family:Consolas">}</span><span style=3D"line-height:115%;=
font-size:9.5pt;font-family:Consolas"></span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US">It looks
pretty simple and straightforward yet it does not work. So yes, it worries =
me
enough to think about it, ask about it, and look for good practice, advices=
 and
alternatives. Others think the risk is worth the benefits. I completly resp=
ect that.<br></span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US">So yes, you are
right, I should get more experience, that&#39;s exactly what I am doing rig=
ht here, right now. I haven=92t been seriously coding in C++ for
the past ten years - you do not have ownership issues when passing around
string in C# - and I am learning this language anew, on my free time. I
definitively lack confidence, that=92s why I am glad when the design of the
classes, or the compiler, help me.</span></p></div></blockquote><div><br></=
div><div>For the above case, you should gain more assistance in future: com=
pilers will implement the deprecation warning pointing out that your class =
&quot;Person&quot; is incorrect. That doesn&#39;t entirely address the prob=
lem, though: there are still risks with idiomatic use of string_view and si=
milar types, and we need to be aware that these are reference-like types in=
 order to use them safely. It may not be obvious to a novice that this code=
 is buggy:</div>
<div><br></div><div>=A0 string_view foo() {</div><div>=A0 =A0 string s;</di=
v><div>=A0 =A0 // ...</div><div>=A0 =A0 return s;</div><div>=A0 }</div><div=
><br></div><div>... and this is currently a worse problem than if &#39;foo&=
#39; returns &#39;string&amp;&#39;, since compilers don&#39;t catch this bu=
g today.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">

<p class=3D"MsoNormal"><span lang=3D"EN-US">And that=92s also
why I am grateful to all the people who took the time to reply to me.</span=
></p>



<p class=3D"MsoNormal"><span lang=3D"EN-US">Best
regards,</span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-US">Vincent
JACQUET</span></p><div><div class=3D"h5">

<br><br>On Friday, October 11, 2013 12:35:33 PM UTC+2, <a href=3D"mailto:st=
ackm...@hotmail.com" target=3D"_blank">stackm...@hotmail.com</a> wrote:<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">What a pointless thread. Thread creator doesn&#39;t seem t=
o have any experience with text processing at all, but supposedly string_vi=
ew is broken because it doesn&#39;t have the semantics he expects.<br><br>
I suggest you first get some experience, you are just wrong and ignorant.<b=
r></div></blockquote></div></div></div><div class=3D"HOEnZb"><div class=3D"=
h5">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--20cf307d064a1a4c4504e87e9e66--

.

------=_Part_109_24944330.1381577775118
Content-Type: text/plain; charset=ISO-8859-1

Thanks, your remarks helped me understand the bug that eluded me. At first,
I used the rule of zero and I added the move ctor for debug purposes but I
forgot the move assignment operator. With a modified Person class, the code
behave exactly like I expected, i.e. it fails when I excepted it to fail.

The code sample assumes 3 things:
1) moving a string moves its data
2) there is no copy involved anywhere
3) because they are in the same class, the view will not outlive the string.

It works fine with long strings.
The problem is the first assumption: because of small strings optimization,
moving a small string actually copies it (please note that I am not
suggesting it is a defect in the string implementation). Therefore the view
is invalidated on small string but not on long strings.

I understood this by accident. I was actually trying to write some code to
show if using auto and lambda could end up passing a view to another thread
without you noticing.

Anyway, to be fair, I have to admit that finding plausible missuse of
string_view is more difficult that I had first anticipated.

Thanks,
Vincent

PS: This is the modified Person class I used

struct Person {

       string name;

       string_view lastname;



       Person(const string& n) : name(n), lastname(parse_name(name)) {}

       ~Person() {}

       // implement move ctor & assignment otherwise it looks like my
compiler tries to copy

       Person(Person&& p) : name(move(p.name)), lastname(move(p.lastname))
{}

       Person& operator =(Person&& p) {

             name = move(p.name);

             lastname = move(p.lastname);

             return *this;

       }



       friend bool operator <(const Person& x, const Person& y) {

             return x.lastname < y.lastname;

       }



private:

       Person(const Person& p); // my compiler does not support = delete

       Person& operator =(const Person& 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_109_24944330.1381577775118
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks, your remarks helped me understand the bug that elu=
ded me. At first, I used the rule of zero and I added the move ctor for deb=
ug purposes but I forgot the move assignment operator. With a modified Pers=
on class, the code behave exactly like I expected, i.e. it fails when I exc=
epted it to fail.<br><br>The code sample assumes 3 things:<br>1) moving a s=
tring moves its data<br>2) there is no copy involved anywhere<br>3) because=
 they are in the same class, the view will not outlive the string.<br><br>I=
t works fine with long strings.<br>The problem is the first assumption: bec=
ause of small strings optimization, moving a small string actually copies i=
t (please note that I am not suggesting it is a defect in the string implem=
entation). Therefore the view is invalidated on small string but not on lon=
g strings.<br><br>I understood this by accident. I was actually trying to w=
rite some code to show if using auto and lambda could end up passing a view=
 to another thread without you noticing.<br><br>Anyway, to be fair, I have =
to admit that finding plausible missuse of string_view is more difficult th=
at I had first anticipated.<br><br>Thanks,<br>Vincent<br><br>PS: This is th=
e modified Person class I used<br><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:DoNotShowComments/>
  <w:HyphenationZone>21</w:HyphenationZone>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>FR</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:DontVertAlignCellWithSp/>
   <w:DontBreakConstrainedForcedTables/>
   <w:DontVertAlignInTxbx/>
   <w:Word11KerningPairs/>
   <w:CachedColBalance/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
  <m:mathPr>
   <m:mathFont m:val=3D"Cambria Math"/>
   <m:brkBin m:val=3D"before"/>
   <m:brkBinSub m:val=3D"&#45;-"/>
   <m:smallFrac m:val=3D"off"/>
   <m:dispDef/>
   <m:lMargin m:val=3D"0"/>
   <m:rMargin m:val=3D"0"/>
   <m:defJc m:val=3D"centerGroup"/>
   <m:wrapIndent m:val=3D"1440"/>
   <m:intLim m:val=3D"subSup"/>
   <m:naryLim m:val=3D"undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]-->

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">struct</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">Person</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> {</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;
background:white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US=
">string</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:bl=
ack;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> name;</s=
pan></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;
background:white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US=
">string_view</span><span style=3D"font-size:9.5pt;font-family:Consolas;col=
or:black;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> lastname=
;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Person(</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">const</sp=
an><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgrou=
nd:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;background=
:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">string</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&amp; </span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:gray;background:whi=
te;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">n</span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">) : name(</span=
><span style=3D"font-size:9.5pt;font-family:Consolas;color:gray;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">n</span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">), lastname(par=
se_name(name)) {}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>~Person()
{}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:green;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">// implem=
ent move ctor &amp;
assignment otherwise it looks like my compiler tries to copy</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Person(</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;
background:white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US=
">Person</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:bl=
ack;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&amp;&amp=
; </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:gray;bac=
kground:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">p</span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:w=
hite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">) : name(move(<=
/span><span style=3D"font-size:9.5pt;font-family:Consolas;color:gray;backgr=
ound:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">p</span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:w=
hite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">.name)), lastna=
me(move(</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:gr=
ay;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">p</span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:w=
hite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">.lastname)) {}<=
/span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;
background:white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US=
">Person</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:bl=
ack;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&amp; ope=
rator =3D(</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:=
#2B91AF;
background:white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US=
">Person</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:bl=
ack;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&amp;&amp=
; </span><span style=3D"font-size:9.5pt;font-family:Consolas;color:gray;bac=
kground:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">p</span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:w=
hite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">) {</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span>name
=3D move(</span><span style=3D"font-size:9.5pt;font-family:Consolas;
color:gray;background:white;mso-highlight:white;mso-ansi-language:EN-US" la=
ng=3D"EN-US">p</span><span style=3D"font-size:9.5pt;font-family:Consolas;co=
lor:black;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">.name);</=
span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span>lastname
=3D move(</span><span style=3D"font-size:9.5pt;font-family:Consolas;
color:gray;background:white;mso-highlight:white;mso-ansi-language:EN-US" la=
ng=3D"EN-US">p</span><span style=3D"font-size:9.5pt;font-family:Consolas;co=
lor:black;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">.lastname=
);</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span></span><span style=3D"font-size:9.5pt;font-family:Con=
solas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">return</s=
pan><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgro=
und:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> *</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:w=
hite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">this</span><spa=
n style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whit=
e;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">friend</s=
pan><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgro=
und:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">bool</span><spa=
n style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whit=
e;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> operator &lt;(=
</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;backg=
round:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">const</sp=
an><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgrou=
nd:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;background=
:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">Person</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&amp; x, </span=
><span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:=
white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">const</span><sp=
an style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:whi=
te;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;background:white=
;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">Person</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&amp; y) {</spa=
n></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span></span><span style=3D"font-size:9.5pt;font-family:Con=
solas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">return</s=
pan><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgro=
und:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> x.lastna=
me &lt; y.lastname;</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>}</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&nbsp;</span></=
p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:blue;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">private</span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:w=
hite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">:</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Person(</span>=
<span style=3D"font-size:9.5pt;font-family:Consolas;color:blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">const</sp=
an><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgrou=
nd:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;background=
:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">Person</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&amp; p); </spa=
n><span style=3D"font-size:9.5pt;font-family:Consolas;color:green;backgroun=
d:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">// my compiler =
does not support =3D
delete </span><span style=3D"font-size:9.5pt;font-family:Consolas;
color:black;background:white;mso-highlight:white;mso-ansi-language:EN-US" l=
ang=3D"EN-US"></span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0cm;margin-bottom:.0001pt;lin=
e-height:
normal;mso-layout-grid-align:none;text-autospace:none"><span style=3D"font-=
size:9.5pt;font-family:Consolas;color:black;background:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"><span style=3D"=
mso-tab-count:1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><span s=
tyle=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;
background:white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US=
">Person</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:bl=
ack;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&amp; ope=
rator =3D(</span><span style=3D"font-size:9.5pt;font-family:Consolas;color:=
blue;background:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">const</sp=
an><span style=3D"font-size:9.5pt;font-family:Consolas;color:black;backgrou=
nd:
white;mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US"> </span><=
span style=3D"font-size:9.5pt;font-family:Consolas;color:#2B91AF;background=
:white;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">Person</span><s=
pan style=3D"font-size:9.5pt;font-family:Consolas;color:black;background:wh=
ite;
mso-highlight:white;mso-ansi-language:EN-US" lang=3D"EN-US">&amp; p);</span=
></p>

<p class=3D"MsoNormal"><span style=3D"font-size:9.5pt;line-height:115%;font=
-family:
Consolas;color:black;background:white;mso-highlight:white">};</span></p>

<!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true"
  DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99"
  LatentStyleCount=3D"267">
  <w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" Name=3D"=
heading 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" Name=3D=
"caption"/>
  <w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default Paragraph=
 Font"/>
  <w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
  <w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
  <w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" Name=3D"Placeho=
lder Text"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" Name=3D"Revisio=
n"/>
  <w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
  <w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false"
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"37" Name=3D"Bibliography"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" Name=3D=
"TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]--><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
 {mso-style-name:"Tableau Normal";
 mso-tstyle-rowband-size:0;
 mso-tstyle-colband-size:0;
 mso-style-noshow:yes;
 mso-style-priority:99;
 mso-style-qformat:yes;
 mso-style-parent:"";
 mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
 mso-para-margin-top:0cm;
 mso-para-margin-right:0cm;
 mso-para-margin-bottom:10.0pt;
 mso-para-margin-left:0cm;
 line-height:115%;
 mso-pagination:widow-orphan;
 font-size:11.0pt;
 font-family:"Calibri","sans-serif";
 mso-ascii-font-family:Calibri;
 mso-ascii-theme-font:minor-latin;
 mso-fareast-font-family:"Times New Roman";
 mso-fareast-theme-font:minor-fareast;
 mso-hansi-font-family:Calibri;
 mso-hansi-theme-font:minor-latin;}
</style>
<![endif]--><br><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_109_24944330.1381577775118--

.

------=_Part_355_4947617.1381847123979
Content-Type: text/plain; charset=ISO-8859-1

On Friday, October 11, 2013 7:35:42 PM UTC+2, Jeffrey Yasskin wrote:

> ...


What's the status of string_view anyway?

--

---
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_355_4947617.1381847123979
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 11, 2013 7:35:42 PM UTC+2, Jeffrey Yass=
kin wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">...</blockquote>=
<div><br></div><div>What's the status of string_view anyway?&nbsp;</div></d=
iv>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_355_4947617.1381847123979--

.

On Tue, Oct 15, 2013 at 7:25 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Friday, October 11, 2013 7:35:42 PM UTC+2, Jeffrey Yasskin wrote:
>>
>> ...
>
>
> What's the status of string_view anyway?

It's likely to get into the fundamentals TS in Issaquah (February).
Alisdair is doing a nitpicky review for LWG so that he can push it
through in that meeting.

--

---
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_6151_7635428.1389833839546
Content-Type: text/plain; charset=UTF-8

Sorry about reviving this thread, but I'm curious about whether people are
confident that the string_view name is now stable?  Or is there any chance
that a C++ standard will end up being ratified with it changed back to
string_ref or some other name?



On Tuesday, October 15, 2013 8:57:04 AM UTC-7, Jeffrey Yasskin wrote:
>
> On Tue, Oct 15, 2013 at 7:25 AM, Olaf van der Spek <olafv...@gmail.com<javascript:>>
> wrote:
> > On Friday, October 11, 2013 7:35:42 PM UTC+2, Jeffrey Yasskin wrote:
> >>
> >> ...
> >
> >
> > What's the status of string_view anyway?
>
> It's likely to get into the fundamentals TS in Issaquah (February).
> Alisdair is doing a nitpicky review for LWG so that he can push it
> through in that meeting.
>

--

---
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_6151_7635428.1389833839546
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry about reviving this thread, but I'm curious about wh=
ether people are confident that the string_view name is now stable? &nbsp;O=
r is there any chance that a C++ standard will end up being ratified with i=
t changed back to string_ref or some other name?<div><br></div><div><br><br=
>On Tuesday, October 15, 2013 8:57:04 AM UTC-7, Jeffrey Yasskin wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On Tue, Oct 15, 2013 at 7:25 AM, Ol=
af van der Spek &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"YQiqMOn_r5QJ" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">olafv...@gmail.com=
</a>&gt; wrote:
<br>&gt; On Friday, October 11, 2013 7:35:42 PM UTC+2, Jeffrey Yasskin wrot=
e:
<br>&gt;&gt;
<br>&gt;&gt; ...
<br>&gt;
<br>&gt;
<br>&gt; What's the status of string_view anyway?
<br>
<br>It's likely to get into the fundamentals TS in Issaquah (February).
<br>Alisdair is doing a nitpicky review for LWG so that he can push it
<br>through in that meeting.
<br></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_6151_7635428.1389833839546--

.