------=_Part_8849_1010823121.1446099870636
Content-Type: multipart/alternative;
 boundary="----=_Part_8850_1873770541.1446099870636"

------=_Part_8850_1873770541.1446099870636
Content-Type: text/plain; charset=UTF-8

I was just looking at the fine details of string_view. And it occurred to
me that being able to construct one from an iterator pair might make sense.
Assuming that the string_view internally just stores a Ch* and a size_type
pair. I *think* it could be defined like this:

template <class Ran>
string_view(Ran first, Ran last) {
    s_ = &*first;
    n_ = distance(first, last);
}

or something similar. At first glance, this seems like it would be useful.
Often algorithms which we would use to find a portion of the string will
return an iterator. Which could then be fed into string_view directly :-)

Is there any reason not to support this? Is there something obvious I'm
missing? I suppose we could always manually do this and use the
string_view(const Ch*, size_type) constructor. But I think accepting
iterators directly would make for cleaner, more readable code.

--

---
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_8850_1873770541.1446099870636
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I was just looking at the fine details of string_view. And=
 it occurred to me that being able to construct one from an iterator pair m=
ight make sense. Assuming that the string_view internally just stores a Ch*=
 and a size_type pair. I *think* it could be defined like this:<div><br></d=
iv><div>template &lt;class Ran&gt;</div><div>string_view(Ran first, Ran las=
t) {</div><div>=C2=A0 =C2=A0 s_ =3D &amp;*first;</div><div>=C2=A0 =C2=A0 n_=
 =3D distance(first, last);</div><div>}</div><div><br></div><div>or somethi=
ng similar. At first glance, this seems like it would be useful. Often algo=
rithms which we would use to find a portion of the string will return an it=
erator. Which could then be fed into string_view directly :-)</div><div><br=
></div><div>Is there any reason not to support this? Is there something obv=
ious I&#39;m missing? I suppose we could always manually do this and use th=
e string_view(const Ch*, size_type) constructor. But I think accepting iter=
ators directly would make for cleaner, more readable code.</div></div>

<p></p>

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

------=_Part_8850_1873770541.1446099870636--
------=_Part_8849_1010823121.1446099870636--

.

We need to be able to identify "contiguous" iterators in order to
accept iterators in string_view's constructor. otherwise, ((&*first) +
distance(first, last) - 1) might not be equal to &*(last-1).

On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran <evan.teran@gmail.com> wrote:
> I was just looking at the fine details of string_view. And it occurred to me
> that being able to construct one from an iterator pair might make sense.
> Assuming that the string_view internally just stores a Ch* and a size_type
> pair. I *think* it could be defined like this:
>
> template <class Ran>
> string_view(Ran first, Ran last) {
>     s_ = &*first;
>     n_ = distance(first, last);
> }
>
> or something similar. At first glance, this seems like it would be useful.
> Often algorithms which we would use to find a portion of the string will
> return an iterator. Which could then be fed into string_view directly :-)
>
> Is there any reason not to support this? Is there something obvious I'm
> missing? I suppose we could always manually do this and use the
> string_view(const Ch*, size_type) constructor. But I think accepting
> iterators directly would make for cleaner, more readable code.
>
> --
>
> ---
> 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/.

.

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

Even if you did know that the iterators were contiguous, the proposed
implementation does not work.

string_view(end(), end()) should create a legal string_view, but
dereferencing end as in the given implementation is UB.


On Thu, Oct 29, 2015 at 2:02 AM, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> We need to be able to identify "contiguous" iterators in order to
> accept iterators in string_view's constructor. otherwise, ((&*first) +
> distance(first, last) - 1) might not be equal to &*(last-1).
>
> On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran <evan.teran@gmail.com> wrote:
> > I was just looking at the fine details of string_view. And it occurred
> to me
> > that being able to construct one from an iterator pair might make sense.
> > Assuming that the string_view internally just stores a Ch* and a
> size_type
> > pair. I *think* it could be defined like this:
> >
> > template <class Ran>
> > string_view(Ran first, Ran last) {
> >     s_ = &*first;
> >     n_ = distance(first, last);
> > }
> >
> > or something similar. At first glance, this seems like it would be
> useful.
> > Often algorithms which we would use to find a portion of the string will
> > return an iterator. Which could then be fed into string_view directly :-)
> >
> > Is there any reason not to support this? Is there something obvious I'm
> > missing? I suppose we could always manually do this and use the
> > string_view(const Ch*, size_type) constructor. But I think accepting
> > iterators directly would make for cleaner, more readable code.
> >
> > --
> >
> > ---
> > 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/.
>

--

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

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

<div dir=3D"ltr">Even if you did know that the iterators were contiguous, t=
he proposed implementation does not work.<div><br></div><div><div>string_vi=
ew(end(), end()) should create a legal string_view, but dereferencing end a=
s in the given implementation is UB.</div><div><br></div></div></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Oct 29, 2015 at=
 2:02 AM, &#39;Jeffrey Yasskin&#39; via ISO C++ Standard - Future Proposals=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=
=3D"_blank">std-proposals@isocpp.org</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">We need to be able to identify &quot;contiguous&quot; ite=
rators in order to<br>
accept iterators in string_view&#39;s constructor. otherwise, ((&amp;*first=
) +<br>
distance(first, last) - 1) might not be equal to &amp;*(last-1).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran &lt;<a href=3D"mailto:evan.tera=
n@gmail.com">evan.teran@gmail.com</a>&gt; wrote:<br>
&gt; I was just looking at the fine details of string_view. And it occurred=
 to me<br>
&gt; that being able to construct one from an iterator pair might make sens=
e.<br>
&gt; Assuming that the string_view internally just stores a Ch* and a size_=
type<br>
&gt; pair. I *think* it could be defined like this:<br>
&gt;<br>
&gt; template &lt;class Ran&gt;<br>
&gt; string_view(Ran first, Ran last) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0s_ =3D &amp;*first;<br>
&gt;=C2=A0 =C2=A0 =C2=A0n_ =3D distance(first, last);<br>
&gt; }<br>
&gt;<br>
&gt; or something similar. At first glance, this seems like it would be use=
ful.<br>
&gt; Often algorithms which we would use to find a portion of the string wi=
ll<br>
&gt; return an iterator. Which could then be fed into string_view directly =
:-)<br>
&gt;<br>
&gt; Is there any reason not to support this? Is there something obvious I&=
#39;m<br>
&gt; missing? I suppose we could always manually do this and use the<br>
&gt; string_view(const Ch*, size_type) constructor. But I think accepting<b=
r>
&gt; iterators directly would make for cleaner, more readable code.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 rel=3D"noreferrer" target=3D"_blank">http://groups.google.com/a/isocpp.org=
/group/std-proposals/</a>.<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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--047d7bd6b514a841c005233936d5--

.

------=_Part_9124_267743453.1446128667816
Content-Type: multipart/alternative;
 boundary="----=_Part_9125_1730764730.1446128667816"

------=_Part_9125_1730764730.1446128667816
Content-Type: text/plain; charset=UTF-8


@Jeffery, that's a fair enough point. But could probably be addressed by
saying "the result is undefined if the iterators are not part of the same
contiguous sequence" or similar. There's lot of things in c++ that if you
pas the wrong parameters, it is simply undefined. For example, just about
every algorithm.

@Brent, another valid point, but easy enough to fix:

template <class Ran>
string_view(Ran first, Ran last) {
    if(first != last) {
        s_ = &*first;
        n_ = distance(first, last);
    } else {
        s_ = nullptr;
        n_ = 0;
    }
}

Both of these points are reasonable, but don't seem insurmountable. Anyway,
thanks for quick thoughts on this.

--

---
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_9125_1730764730.1446128667816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div>@Jeffery, that&#39;s a fair enough point. B=
ut could probably be addressed by saying &quot;the result is undefined if t=
he iterators are not part of the same contiguous sequence&quot; or similar.=
 There&#39;s lot of things in c++ that if you pas the wrong parameters, it =
is simply undefined. For example, just about every algorithm.<div><br></div=
><div>@Brent, another valid point, but easy enough to fix:</div><div><br></=
div><div><div>template &lt;class Ran&gt;</div><div>string_view(Ran first, R=
an last) {</div><div>=C2=A0 =C2=A0 if(first !=3D last) {</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 s_ =3D &amp;*first;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 n_ =3D distance(first, last);</div><div>=C2=A0 =C2=A0 } else {</div><di=
v>=C2=A0 =C2=A0 =C2=A0 =C2=A0 s_ =3D nullptr;</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 n_ =3D 0;</div><div>=C2=A0 =C2=A0 }</div><div>}</div></div><div>=
<br></div><div>Both of these points are reasonable, but don&#39;t seem insu=
rmountable. Anyway, thanks for quick thoughts on this.</div></div>

<p></p>

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

------=_Part_9125_1730764730.1446128667816--
------=_Part_9124_267743453.1446128667816--

.

------=_Part_1970_441021334.1446133443784
Content-Type: multipart/alternative;
 boundary="----=_Part_1971_1203380454.1446133443792"

------=_Part_1971_1203380454.1446133443792
Content-Type: text/plain; charset=UTF-8



>
> string_view(end(), end()) should create a legal string_view, but
> dereferencing end as in the given implementation is UB.
>
> Enlighten me: I don't see what the problem is here. The created
string_view has two equal iterators so n_ would be 0. Of course it is not
allowed to dereference the object using for instance operator[] but
that's always true of an empty string_view, isn't it?

The only thing the "solution" that Even suggests changes is that the
subtraction of two equal iterators is replaced with a != test. I can't see
that this could be a problem for an iterator type that has operator-
defined. That would mean that
there would be iterator values that compare equal but don't return 0 when
subtracted from each other. That's bizarre (even though it is possible to
construct such classes of course, with (im)proper overloads). I see the
problem for non-random access iterators where one can be some kind of
sentinel, but then operator- is not defined anyway... and typically the
iterator type for the ends are different which is not supported in the
suggested API.


>
> On Thu, Oct 29, 2015 at 2:02 AM, 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> We need to be able to identify "contiguous" iterators in order to
>> accept iterators in string_view's constructor. otherwise, ((&*first) +
>> distance(first, last) - 1) might not be equal to &*(last-1).
>>
>> On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran <evan....@gmail.com
>> <javascript:>> wrote:
>> > I was just looking at the fine details of string_view. And it occurred
>> to me
>> > that being able to construct one from an iterator pair might make sense.
>> > Assuming that the string_view internally just stores a Ch* and a
>> size_type
>> > pair. I *think* it could be defined like this:
>> >
>> > template <class Ran>
>> > string_view(Ran first, Ran last) {
>> >     s_ = &*first;
>> >     n_ = distance(first, last);
>> > }
>> >
>> > or something similar. At first glance, this seems like it would be
>> useful.
>> > Often algorithms which we would use to find a portion of the string will
>> > return an iterator. Which could then be fed into string_view directly
>> :-)
>> >
>> > Is there any reason not to support this? Is there something obvious I'm
>> > missing? I suppose we could always manually do this and use the
>> > string_view(const Ch*, size_type) constructor. But I think accepting
>> > iterators directly would make for cleaner, more readable code.
>> >
>> > --
>> >
>> > ---
>> > 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_1971_1203380454.1446133443792
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><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"><div><br></div><div><div>string_view(end(), end()) should create a=
 legal string_view, but dereferencing end as in the given implementation is=
 UB.</div><div><br></div></div></div></blockquote><div>Enlighten me: I don&=
#39;t see what the problem is here. The created string_view has two equal i=
terators so n_ would be 0. Of course it is not allowed to dereference the o=
bject using for instance operator[] but</div><div>that&#39;s always true of=
 an empty string_view, isn&#39;t it?</div><div><br></div><div>The only thin=
g the &quot;solution&quot; that Even suggests changes is that the subtracti=
on of two equal iterators is replaced with a !=3D test. I can&#39;t see tha=
t this could be a problem for an iterator type that has operator- defined. =
That would mean that</div><div>there would be iterator values that compare =
equal but don&#39;t return 0 when subtracted from each other. That&#39;s bi=
zarre (even though it is possible to construct such classes of course, with=
 (im)proper overloads). I see the problem for non-random access iterators w=
here one can be some kind of sentinel, but then operator- is not defined an=
yway... and typically the iterator type for the ends are different which is=
 not supported in the suggested API.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div></div></div></div><=
div><br><div class=3D"gmail_quote">On Thu, Oct 29, 2015 at 2:02 AM, &#39;Je=
ffrey Yasskin&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr=
">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"do=
L0fFMcEwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#3=
9;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;"=
>std-pr...@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">We need to be able to identify &quot;contiguous&quot; iterators in order=
 to<br>
accept iterators in string_view&#39;s constructor. otherwise, ((&amp;*first=
) +<br>
distance(first, last) - 1) might not be equal to &amp;*(last-1).<br>
<div><div><br>
On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran &lt;<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"doL0fFMcEwAJ" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.=
href=3D&#39;javascript:&#39;;return true;">evan....@gmail.com</a>&gt; wrote=
:<br>
&gt; I was just looking at the fine details of string_view. And it occurred=
 to me<br>
&gt; that being able to construct one from an iterator pair might make sens=
e.<br>
&gt; Assuming that the string_view internally just stores a Ch* and a size_=
type<br>
&gt; pair. I *think* it could be defined like this:<br>
&gt;<br>
&gt; template &lt;class Ran&gt;<br>
&gt; string_view(Ran first, Ran last) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0s_ =3D &amp;*first;<br>
&gt;=C2=A0 =C2=A0 =C2=A0n_ =3D distance(first, last);<br>
&gt; }<br>
&gt;<br>
&gt; or something similar. At first glance, this seems like it would be use=
ful.<br>
&gt; Often algorithms which we would use to find a portion of the string wi=
ll<br>
&gt; return an iterator. Which could then be fed into string_view directly =
:-)<br>
&gt;<br>
&gt; Is there any reason not to support this? Is there something obvious I&=
#39;m<br>
&gt; missing? I suppose we could always manually do this and use the<br>
&gt; string_view(const Ch*, size_type) constructor. But I think accepting<b=
r>
&gt; iterators directly would make for cleaner, more readable code.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"doL0fFMcEwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"doL0fFMcEwAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://=
groups.google.com/a/isocpp.org/group/std-proposals/&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-pro=
posals/&#39;;return true;">http://groups.google.com/a/<wbr>isocpp.org/group=
/std-<wbr>proposals/</a>.<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
doL0fFMcEwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">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"doL0fFMcEwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

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

------=_Part_1971_1203380454.1446133443792--
------=_Part_1970_441021334.1446133443784--

.

------=_Part_9156_1359801344.1446134214811
Content-Type: multipart/alternative;
 boundary="----=_Part_9157_1589029334.1446134214811"

------=_Part_9157_1589029334.1446134214811
Content-Type: text/plain; charset=UTF-8

@Bengt,

So I think the part that Brent was objecting to was the unconditional "s_ =
&*first;" in the initial version. The concern being the deference then
reference of end() if given string_view(end(), end()); But as shown, this
is trivially worked around.

I agree about your assessment of the iterators. And I also thought it was
important to insist that the iterators be rand access for a couple of
reasons:

1. std::distance would be O(1)
2. last would have to be not a sentinel (I think a sentinel is incompatible
with being a random access, right?)

We could simplify the constructor slightly like this:

template <class Ran>
string_view(Ran first, Ran last) {
    n_ = distance(first, last);
    if(n_ != 0) {
        s_ = &*first;
    } else {
        s_ = nullptr;
    }
}

Then we don't need to directly compare the iterators, we only care if there
is any distance between them. Thus avoiding the bizarre case of iterators
that are equal but have a distance. (which is honestly evil, i hope no one
does that)


On Thursday, October 29, 2015 at 11:44:03 AM UTC-4, Bengt Gustafsson wrote:
>
>
>
>> string_view(end(), end()) should create a legal string_view, but
>> dereferencing end as in the given implementation is UB.
>>
>> Enlighten me: I don't see what the problem is here. The created
> string_view has two equal iterators so n_ would be 0. Of course it is not
> allowed to dereference the object using for instance operator[] but
> that's always true of an empty string_view, isn't it?
>
> The only thing the "solution" that Even suggests changes is that the
> subtraction of two equal iterators is replaced with a != test. I can't see
> that this could be a problem for an iterator type that has operator-
> defined. That would mean that
> there would be iterator values that compare equal but don't return 0 when
> subtracted from each other. That's bizarre (even though it is possible to
> construct such classes of course, with (im)proper overloads). I see the
> problem for non-random access iterators where one can be some kind of
> sentinel, but then operator- is not defined anyway... and typically the
> iterator type for the ends are different which is not supported in the
> suggested API.
>
>
>>
>> On Thu, Oct 29, 2015 at 2:02 AM, 'Jeffrey Yasskin' via ISO C++ Standard -
>> Future Proposals <std-pr...@isocpp.org> wrote:
>>
>>> We need to be able to identify "contiguous" iterators in order to
>>> accept iterators in string_view's constructor. otherwise, ((&*first) +
>>> distance(first, last) - 1) might not be equal to &*(last-1).
>>>
>>> On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran <evan....@gmail.com> wrote:
>>> > I was just looking at the fine details of string_view. And it occurred
>>> to me
>>> > that being able to construct one from an iterator pair might make
>>> sense.
>>> > Assuming that the string_view internally just stores a Ch* and a
>>> size_type
>>> > pair. I *think* it could be defined like this:
>>> >
>>> > template <class Ran>
>>> > string_view(Ran first, Ran last) {
>>> >     s_ = &*first;
>>> >     n_ = distance(first, last);
>>> > }
>>> >
>>> > or something similar. At first glance, this seems like it would be
>>> useful.
>>> > Often algorithms which we would use to find a portion of the string
>>> will
>>> > return an iterator. Which could then be fed into string_view directly
>>> :-)
>>> >
>>> > Is there any reason not to support this? Is there something obvious I'm
>>> > missing? I suppose we could always manually do this and use the
>>> > string_view(const Ch*, size_type) constructor. But I think accepting
>>> > iterators directly would make for cleaner, more readable code.
>>> >
>>> > --
>>> >
>>> > ---
>>> > 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/.
>>>
>>> --
>>>
>>> ---
>>> 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/.
>>>
>>
>>

--

---
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_9157_1589029334.1446134214811
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@Bengt,<div><br></div><div>So I think the part that Brent =
was objecting to w<font color=3D"#000000">as the unconditional <font face=
=3D"courier new, monospace">&quot;s_ =3D &amp;*first;</font>&quot; in the i=
nitial version. The concern being the=C2=A0deference=C2=A0then reference of=
 <font face=3D"courier new, monospace">end()</font> if given <font face=3D"=
courier new, monospace">string_view(end(), end());</font><font face=3D"aria=
l, sans-serif">=C2=A0But as shown, this is trivially worked around.</font><=
/font></div><div><font color=3D"#000000" face=3D"arial, sans-serif"><br></f=
ont></div><div><font color=3D"#000000" face=3D"arial, sans-serif">I agree a=
bout your assessment of the iterators. And I also thought it was important =
to insist that the iterators be rand access for a couple of reasons:</font>=
</div><div><font color=3D"#000000" face=3D"arial, sans-serif"><br></font></=
div><div><font color=3D"#000000" face=3D"arial, sans-serif">1. </font><font=
 color=3D"#000000" face=3D"courier new, monospace">std::distance</font><fon=
t color=3D"#000000" face=3D"arial, sans-serif"> would be O(1)</font></div><=
div><font color=3D"#000000" face=3D"arial, sans-serif">2. </font><font colo=
r=3D"#000000" face=3D"courier new, monospace">last</font><font color=3D"#00=
0000" face=3D"arial, sans-serif"> would have to be not a=C2=A0</font><span =
style=3D"color: rgb(0, 0, 0); font-family: arial, sans-serif;">sentinel=C2=
=A0</span><font color=3D"#000000" face=3D"arial, sans-serif">(I think a sen=
tinel is incompatible with being a random access, right?)</font></div><div>=
<font color=3D"#000000" face=3D"arial, sans-serif"><br></font></div><div><f=
ont color=3D"#000000" face=3D"arial, sans-serif">We could simplify the cons=
tructor slightly like this:</font></div><div><font color=3D"#000000" face=
=3D"arial, sans-serif"><br></font></div><div><div class=3D"IVILX2C-Db-b"><d=
iv><font face=3D"courier new, monospace" color=3D"#000000">template &lt;cla=
ss Ran&gt;</font></div><div><font face=3D"courier new, monospace" color=3D"=
#000000">string_view(Ran first, Ran last) {</font></div><div><font face=3D"=
courier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 n_ =3D distance(fir=
st, last);</font></div></div><div><font face=3D"courier new, monospace" col=
or=3D"#000000">=C2=A0 =C2=A0 if(n_ !=3D 0) {</font></div><div class=3D"IVIL=
X2C-Db-b"><div><font face=3D"courier new, monospace" color=3D"#000000">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 s_ =3D &amp;*first; =C2=A0 =C2=A0 =C2=A0 =C2=A0</f=
ont></div></div><div><font face=3D"courier new, monospace" color=3D"#000000=
">=C2=A0 =C2=A0 } else {</font></div><div><font face=3D"courier new, monosp=
ace" color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 s_ =3D nullptr;</font></=
div><div><font face=3D"courier new, monospace" color=3D"#000000">=C2=A0 =C2=
=A0 }</font></div><div><font face=3D"courier new, monospace" color=3D"#0000=
00">}</font></div><div><font face=3D"courier new, monospace" color=3D"#0000=
00"><br></font></div><div><font color=3D"#000000" face=3D"arial, sans-serif=
">Then we don&#39;t need to directly compare the iterators, we only care if=
 there is any distance between them. Thus avoiding the bizarre case of iter=
ators that are equal but have a distance. (which is honestly evil, i hope n=
o one does that)</font></div><br><br></div><div>On Thursday, October 29, 20=
15 at 11:44:03 AM UTC-4, Bengt Gustafsson wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div><br></div><div><div>string_view(end(), end()) sho=
uld create a legal string_view, but dereferencing end as in the given imple=
mentation is UB.</div><div><br></div></div></div></blockquote><div>Enlighte=
n me: I don&#39;t see what the problem is here. The created string_view has=
 two equal iterators so n_ would be 0. Of course it is not allowed to deref=
erence the object using for instance operator[] but</div><div>that&#39;s al=
ways true of an empty string_view, isn&#39;t it?</div><div><br></div><div>T=
he only thing the &quot;solution&quot; that Even suggests changes is that t=
he subtraction of two equal iterators is replaced with a !=3D test. I can&#=
39;t see that this could be a problem for an iterator type that has operato=
r- defined. That would mean that</div><div>there would be iterator values t=
hat compare equal but don&#39;t return 0 when subtracted from each other. T=
hat&#39;s bizarre (even though it is possible to construct such classes of =
course, with (im)proper overloads). I see the problem for non-random access=
 iterators where one can be some kind of sentinel, but then operator- is no=
t defined anyway... and typically the iterator type for the ends are differ=
ent which is not supported in the suggested API.</div><div>=C2=A0</div><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"><div><div></div></div>=
</div><div><br><div class=3D"gmail_quote">On Thu, Oct 29, 2015 at 2:02 AM, =
&#39;Jeffrey Yasskin&#39; via ISO C++ Standard - Future Proposals <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">std-pr...@isocpp.org</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">We need to be able to identify &quot;con=
tiguous&quot; iterators in order to<br>
accept iterators in string_view&#39;s constructor. otherwise, ((&amp;*first=
) +<br>
distance(first, last) - 1) might not be equal to &amp;*(last-1).<br>
<div><div><br>
On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran &lt;<a rel=3D"nofollow">evan...=
..@gmail.com</a>&gt; wrote:<br>
&gt; I was just looking at the fine details of string_view. And it occurred=
 to me<br>
&gt; that being able to construct one from an iterator pair might make sens=
e.<br>
&gt; Assuming that the string_view internally just stores a Ch* and a size_=
type<br>
&gt; pair. I *think* it could be defined like this:<br>
&gt;<br>
&gt; template &lt;class Ran&gt;<br>
&gt; string_view(Ran first, Ran last) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0s_ =3D &amp;*first;<br>
&gt;=C2=A0 =C2=A0 =C2=A0n_ =3D distance(first, last);<br>
&gt; }<br>
&gt;<br>
&gt; or something similar. At first glance, this seems like it would be use=
ful.<br>
&gt; Often algorithms which we would use to find a portion of the string wi=
ll<br>
&gt; return an iterator. Which could then be fed into string_view directly =
:-)<br>
&gt;<br>
&gt; Is there any reason not to support this? Is there something obvious I&=
#39;m<br>
&gt; missing? I suppose we could always manually do this and use the<br>
&gt; string_view(const Ch*, size_type) constructor. But I think accepting<b=
r>
&gt; iterators directly would make for cleaner, more readable code.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://=
groups.google.com/a/isocpp.org/group/std-proposals/&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-pro=
posals/&#39;;return true;">http://groups.google.com/a/<wbr>isocpp.org/group=
/std-<wbr>proposals/</a>.<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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></blockquote></div></div>

<p></p>

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

------=_Part_9157_1589029334.1446134214811--
------=_Part_9156_1359801344.1446134214811--

.

------=_Part_10089_1806264413.1446135261112
Content-Type: multipart/alternative;
 boundary="----=_Part_10090_1875377.1446135261112"

------=_Part_10090_1875377.1446135261112
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 11:56:54 AM UTC-4, Evan Teran wrote:
>
> I agree about your assessment of the iterators. And I also thought it was
> important to insist that the iterators be rand access for a couple of
> reasons:
>

They don't have to be random access; they have to be *contiguous*. That's a
higher standard. `deque` provides random access iterators, but you can't
stick `deque<char>` iterators into a `string_view`.

--

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

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

<div dir=3D"ltr">On Thursday, October 29, 2015 at 11:56:54 AM UTC-4, Evan T=
eran wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><font face=3D"arial, sans-serif" color=3D"#000000">I agree about your as=
sessment of the iterators. And I also thought it was important to insist th=
at the iterators be rand access for a couple of reasons:</font></div></div>=
</blockquote><div><br>They don&#39;t have to be random access; they have to=
 be *contiguous*. That&#39;s a higher standard. `deque` provides random acc=
ess iterators, but you can&#39;t stick `deque&lt;char&gt;` iterators into a=
 `string_view`.</div></div>

<p></p>

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

------=_Part_10090_1875377.1446135261112--
------=_Part_10089_1806264413.1446135261112--

.

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

Evan,

Yes that does address the issue I was raising. Of course, if strings and
vectors used pointer iterators then we wouldn't need the if test or the
overload at all.

I think this constructor has a lot of room to be accidentally abused,
however.

One way to work around this is with a "make_*" style utility that uses
domain knowledge to convert iterators. For example,

string_view make_string_view(array<char>::iterator b, array<char>::iterator
e);
string_view make_string_view(vector<char>::iterator b,
vector<char>::iterator e);
string_view make_string_view(string::iterator b, string::iterator e);

You can then overload make_string_view to support your own iterator types
if you know that they are contiguous.

I'll also point out that contiguous iterators are not sufficient; begin
must also be less than end from the perspective of its underlying memory
location. IE, it doesn't work with reverse_iterator (and cannot be made to).

On Thu, Oct 29, 2015 at 10:56 AM, Evan Teran <evan.teran@gmail.com> wrote:

> @Bengt,
>
> So I think the part that Brent was objecting to was the unconditional "s_
> = &*first;" in the initial version. The concern being the deference then
> reference of end() if given string_view(end(), end()); But as shown, this
> is trivially worked around.
>
> I agree about your assessment of the iterators. And I also thought it was
> important to insist that the iterators be rand access for a couple of
> reasons:
>
> 1. std::distance would be O(1)
> 2. last would have to be not a sentinel (I think a sentinel is
> incompatible with being a random access, right?)
>
> We could simplify the constructor slightly like this:
>
> template <class Ran>
> string_view(Ran first, Ran last) {
>     n_ = distance(first, last);
>     if(n_ != 0) {
>         s_ = &*first;
>     } else {
>         s_ = nullptr;
>     }
> }
>
> Then we don't need to directly compare the iterators, we only care if
> there is any distance between them. Thus avoiding the bizarre case of
> iterators that are equal but have a distance. (which is honestly evil, i
> hope no one does that)
>
>
> On Thursday, October 29, 2015 at 11:44:03 AM UTC-4, Bengt Gustafsson wrote:
>>
>>
>>
>>> string_view(end(), end()) should create a legal string_view, but
>>> dereferencing end as in the given implementation is UB.
>>>
>>> Enlighten me: I don't see what the problem is here. The created
>> string_view has two equal iterators so n_ would be 0. Of course it is not
>> allowed to dereference the object using for instance operator[] but
>> that's always true of an empty string_view, isn't it?
>>
>> The only thing the "solution" that Even suggests changes is that the
>> subtraction of two equal iterators is replaced with a != test. I can't see
>> that this could be a problem for an iterator type that has operator-
>> defined. That would mean that
>> there would be iterator values that compare equal but don't return 0 when
>> subtracted from each other. That's bizarre (even though it is possible to
>> construct such classes of course, with (im)proper overloads). I see the
>> problem for non-random access iterators where one can be some kind of
>> sentinel, but then operator- is not defined anyway... and typically the
>> iterator type for the ends are different which is not supported in the
>> suggested API.
>>
>>
>>>
>>> On Thu, Oct 29, 2015 at 2:02 AM, 'Jeffrey Yasskin' via ISO C++ Standard
>>> - Future Proposals <std-pr...@isocpp.org> wrote:
>>>
>>>> We need to be able to identify "contiguous" iterators in order to
>>>> accept iterators in string_view's constructor. otherwise, ((&*first) +
>>>> distance(first, last) - 1) might not be equal to &*(last-1).
>>>>
>>>> On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran <evan....@gmail.com> wrote:
>>>> > I was just looking at the fine details of string_view. And it
>>>> occurred to me
>>>> > that being able to construct one from an iterator pair might make
>>>> sense.
>>>> > Assuming that the string_view internally just stores a Ch* and a
>>>> size_type
>>>> > pair. I *think* it could be defined like this:
>>>> >
>>>> > template <class Ran>
>>>> > string_view(Ran first, Ran last) {
>>>> >     s_ = &*first;
>>>> >     n_ = distance(first, last);
>>>> > }
>>>> >
>>>> > or something similar. At first glance, this seems like it would be
>>>> useful.
>>>> > Often algorithms which we would use to find a portion of the string
>>>> will
>>>> > return an iterator. Which could then be fed into string_view directly
>>>> :-)
>>>> >
>>>> > Is there any reason not to support this? Is there something obvious
>>>> I'm
>>>> > missing? I suppose we could always manually do this and use the
>>>> > string_view(const Ch*, size_type) constructor. But I think accepting
>>>> > iterators directly would make for cleaner, more readable code.
>>>> >
>>>> > --
>>>> >
>>>> > ---
>>>> > 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/.
>>>>
>>>> --
>>>>
>>>> ---
>>>> 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/.
>>>>
>>>
>>> --
>
> ---
> 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/.

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

<div dir=3D"ltr">Evan,<div><br></div><div>Yes that does address the issue I=
 was raising. Of course, if strings and vectors used pointer iterators then=
 we wouldn&#39;t need the if test or the overload at all.</div><div><br></d=
iv><div>I think this constructor has a lot of room to be accidentally abuse=
d, however.</div><div><br></div><div>One way to work around this is with a =
&quot;make_*&quot; style utility that uses domain knowledge to convert iter=
ators. For example,</div><div><br></div><div>string_view make_string_view(a=
rray&lt;char&gt;::iterator b, array&lt;char&gt;::iterator e);</div><div>str=
ing_view make_string_view(vector&lt;char&gt;::iterator b, vector&lt;char&gt=
;::iterator e);</div><div>string_view make_string_view(string::iterator b, =
string::iterator e);</div><div><br></div><div>You can then overload make_st=
ring_view to support your own iterator types if you know that they are cont=
iguous.</div><div><br></div><div>I&#39;ll also point out that contiguous it=
erators are not sufficient; begin must also be less than end from the persp=
ective of its underlying memory location. IE, it doesn&#39;t work with reve=
rse_iterator (and cannot be made to).</div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Thu, Oct 29, 2015 at 10:56 AM, Evan Tera=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:evan.teran@gmail.com" target=3D"_=
blank">evan.teran@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">@Bengt,<div><br></div><div>So I think the part th=
at Brent was objecting to w<font color=3D"#000000">as the unconditional <fo=
nt face=3D"courier new, monospace">&quot;s_ =3D &amp;*first;</font>&quot; i=
n the initial version. The concern being the=C2=A0deference=C2=A0then refer=
ence of <font face=3D"courier new, monospace">end()</font> if given <font f=
ace=3D"courier new, monospace">string_view(end(), end());</font><font face=
=3D"arial, sans-serif">=C2=A0But as shown, this is trivially worked around.=
</font></font></div><div><font color=3D"#000000" face=3D"arial, sans-serif"=
><br></font></div><div><font color=3D"#000000" face=3D"arial, sans-serif">I=
 agree about your assessment of the iterators. And I also thought it was im=
portant to insist that the iterators be rand access for a couple of reasons=
:</font></div><div><font color=3D"#000000" face=3D"arial, sans-serif"><br><=
/font></div><div><font color=3D"#000000" face=3D"arial, sans-serif">1. </fo=
nt><font color=3D"#000000" face=3D"courier new, monospace">std::distance</f=
ont><font color=3D"#000000" face=3D"arial, sans-serif"> would be O(1)</font=
></div><div><font color=3D"#000000" face=3D"arial, sans-serif">2. </font><f=
ont color=3D"#000000" face=3D"courier new, monospace">last</font><font colo=
r=3D"#000000" face=3D"arial, sans-serif"> would have to be not a=C2=A0</fon=
t><span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif">sentinel=C2=
=A0</span><font color=3D"#000000" face=3D"arial, sans-serif">(I think a sen=
tinel is incompatible with being a random access, right?)</font></div><div>=
<font color=3D"#000000" face=3D"arial, sans-serif"><br></font></div><div><f=
ont color=3D"#000000" face=3D"arial, sans-serif">We could simplify the cons=
tructor slightly like this:</font></div><div><font color=3D"#000000" face=
=3D"arial, sans-serif"><br></font></div><div><div><span class=3D""><div><fo=
nt face=3D"courier new, monospace" color=3D"#000000">template &lt;class Ran=
&gt;</font></div><div><font face=3D"courier new, monospace" color=3D"#00000=
0">string_view(Ran first, Ran last) {</font></div></span><div><font face=3D=
"courier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 n_ =3D distance(fi=
rst, last);</font></div></div><div><font face=3D"courier new, monospace" co=
lor=3D"#000000">=C2=A0 =C2=A0 if(n_ !=3D 0) {</font></div><div><div><font f=
ace=3D"courier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 s_ =3D &amp;*first; =C2=A0 =C2=A0 =C2=A0 =C2=A0</font></div></div><div>=
<font face=3D"courier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 } els=
e {</font></div><div><font face=3D"courier new, monospace" color=3D"#000000=
">=C2=A0 =C2=A0 =C2=A0 =C2=A0 s_ =3D nullptr;</font></div><div><font face=
=3D"courier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 }</font></div><=
div><font face=3D"courier new, monospace" color=3D"#000000">}</font></div><=
div><font face=3D"courier new, monospace" color=3D"#000000"><br></font></di=
v><div><font color=3D"#000000" face=3D"arial, sans-serif">Then we don&#39;t=
 need to directly compare the iterators, we only care if there is any dista=
nce between them. Thus avoiding the bizarre case of iterators that are equa=
l but have a distance. (which is honestly evil, i hope no one does that)</f=
ont></div><br><br></div><div><div class=3D"h5"><div>On Thursday, October 29=
, 2015 at 11:44:03 AM UTC-4, Bengt Gustafsson wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><br></div><div><div>string_view(end(), end()) shou=
ld create a legal string_view, but dereferencing end as in the given implem=
entation is UB.</div><div><br></div></div></div></blockquote><div>Enlighten=
 me: I don&#39;t see what the problem is here. The created string_view has =
two equal iterators so n_ would be 0. Of course it is not allowed to derefe=
rence the object using for instance operator[] but</div><div>that&#39;s alw=
ays true of an empty string_view, isn&#39;t it?</div><div><br></div><div>Th=
e only thing the &quot;solution&quot; that Even suggests changes is that th=
e subtraction of two equal iterators is replaced with a !=3D test. I can&#3=
9;t see that this could be a problem for an iterator type that has operator=
- defined. That would mean that</div><div>there would be iterator values th=
at compare equal but don&#39;t return 0 when subtracted from each other. Th=
at&#39;s bizarre (even though it is possible to construct such classes of c=
ourse, with (im)proper overloads). I see the problem for non-random access =
iterators where one can be some kind of sentinel, but then operator- is not=
 defined anyway... and typically the iterator type for the ends are differe=
nt which is not supported in the suggested API.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div></div></div><=
/div><div><br><div class=3D"gmail_quote">On Thu, Oct 29, 2015 at 2:02 AM, &=
#39;Jeffrey Yasskin&#39; via ISO C++ Standard - Future Proposals <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">std-pr...@isocpp.org</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">We need to be able to identify &quot;con=
tiguous&quot; iterators in order to<br>
accept iterators in string_view&#39;s constructor. otherwise, ((&amp;*first=
) +<br>
distance(first, last) - 1) might not be equal to &amp;*(last-1).<br>
<div><div><br>
On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran &lt;<a rel=3D"nofollow">evan...=
..@gmail.com</a>&gt; wrote:<br>
&gt; I was just looking at the fine details of string_view. And it occurred=
 to me<br>
&gt; that being able to construct one from an iterator pair might make sens=
e.<br>
&gt; Assuming that the string_view internally just stores a Ch* and a size_=
type<br>
&gt; pair. I *think* it could be defined like this:<br>
&gt;<br>
&gt; template &lt;class Ran&gt;<br>
&gt; string_view(Ran first, Ran last) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0s_ =3D &amp;*first;<br>
&gt;=C2=A0 =C2=A0 =C2=A0n_ =3D distance(first, last);<br>
&gt; }<br>
&gt;<br>
&gt; or something similar. At first glance, this seems like it would be use=
ful.<br>
&gt; Often algorithms which we would use to find a portion of the string wi=
ll<br>
&gt; return an iterator. Which could then be fed into string_view directly =
:-)<br>
&gt;<br>
&gt; Is there any reason not to support this? Is there something obvious I&=
#39;m<br>
&gt; missing? I suppose we could always manually do this and use the<br>
&gt; string_view(const Ch*, size_type) constructor. But I think accepting<b=
r>
&gt; iterators directly would make for cleaner, more readable code.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 rel=3D"nofollow" target=3D"_blank">http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></blockquote></div></div></div></div><div class=3D"HOEnZ=
b"><div class=3D"h5">

<p></p>

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

--001a11c1cb68f9bfa1052340be46--

.

------=_Part_653_1669803613.1446137669604
Content-Type: multipart/alternative;
 boundary="----=_Part_654_1193284616.1446137669605"

------=_Part_654_1193284616.1446137669605
Content-Type: text/plain; charset=UTF-8

On Thursday, October 29, 2015 at 12:24:33 PM UTC-4, Brent Friedman wrote:
>
> Evan,
>
> Yes that does address the issue I was raising. Of course, if strings and
> vectors used pointer iterators then we wouldn't need the if test or the
> overload at all.
>

Even if those two types use pointer iterators, that shouldn't mean that
contiguous iterators *ought* to be pointers. What about range adaptors?
Some of those can be contiguous iterators, but they're certainly not
pointers.

Of course, you wouldn't be able to use range adaptors in string_views
either. They're more for template code. So there's another strike against
this overload. `string_view` is meant for arrays of characters, which in
C++ is specified by pointers.

Ultimately, what you want isn't for std::string and std::vector iterators
to be pointers. You want them to be *convertible* to pointers (and
vice-versa).

--

---
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_654_1193284616.1446137669605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, October 29, 2015 at 12:24:33 PM UTC-4, Brent =
Friedman 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=
">Evan,<div><br></div><div>Yes that does address the issue I was raising. O=
f course, if strings and vectors used pointer iterators then we wouldn&#39;=
t need the if test or the overload at all.</div></div></blockquote><div><br=
>Even if those two types use pointer iterators, that shouldn&#39;t mean tha=
t contiguous iterators <i>ought</i> to be pointers. What about range adapto=
rs? Some of those can be contiguous iterators, but they&#39;re certainly no=
t pointers.<br><br>Of course, you wouldn&#39;t be able to use range adaptor=
s in string_views either. They&#39;re more for template code. So there&#39;=
s another strike against this overload. `string_view` is meant for arrays o=
f characters, which in C++ is specified by pointers.<br><br>Ultimately, wha=
t you want isn&#39;t for std::string and std::vector iterators to be pointe=
rs. You want them to be <i>convertible</i> to pointers (and vice-versa).</d=
iv></div>

<p></p>

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

------=_Part_654_1193284616.1446137669605--
------=_Part_653_1669803613.1446137669604--

.

------=_Part_615_2098889785.1446138462540
Content-Type: multipart/alternative;
 boundary="----=_Part_616_1178035029.1446138462553"

------=_Part_616_1178035029.1446138462553
Content-Type: text/plain; charset=UTF-8


Fair enough. Regarding the contiguous and ordering issues, personally, I
file them under the "give the function bad input, get UB" category, but I
agree that it's a real concern. If too many inputs result in UB, then it's
too easy to misuse or abuse. I think that is enough to make this a
non-starter.

That being said, I actually like the "make_string_view" idea, which could
have overloads for the various things that we know will work. I have
another thought on string_views, but it's mostly unrelated, so I'll make
that a separate post.

Thanks for the feedback.

On Thursday, October 29, 2015 at 12:54:29 PM UTC-4, Nicol Bolas wrote:
>
> On Thursday, October 29, 2015 at 12:24:33 PM UTC-4, Brent Friedman wrote:
>>
>> Evan,
>>
>> Yes that does address the issue I was raising. Of course, if strings and
>> vectors used pointer iterators then we wouldn't need the if test or the
>> overload at all.
>>
>
> Even if those two types use pointer iterators, that shouldn't mean that
> contiguous iterators *ought* to be pointers. What about range adaptors?
> Some of those can be contiguous iterators, but they're certainly not
> pointers.
>
> Of course, you wouldn't be able to use range adaptors in string_views
> either. They're more for template code. So there's another strike against
> this overload. `string_view` is meant for arrays of characters, which in
> C++ is specified by pointers.
>
> Ultimately, what you want isn't for std::string and std::vector iterators
> to be pointers. You want them to be *convertible* to pointers (and
> vice-versa).
>

--

---
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_616_1178035029.1446138462553
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div>Fair enough. Regarding the contiguous and o=
rdering issues, personally, I file them under the &quot;give the function b=
ad input, get UB&quot; category, but I agree that it&#39;s a real concern. =
If too many inputs result in UB, then it&#39;s too easy to misuse or abuse.=
 I think that is enough to make this a non-starter.<div><br></div><div>That=
 being said, I actually like the &quot;make_string_view&quot; idea, which c=
ould have overloads for the various things that we know will work. I have a=
nother thought on string_views, but it&#39;s mostly unrelated, so I&#39;ll =
make that a separate post.</div><div><br></div><div>Thanks for the feedback=
..<br><br>On Thursday, October 29, 2015 at 12:54:29 PM UTC-4, Nicol Bolas wr=
ote:<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 Thursd=
ay, October 29, 2015 at 12:24:33 PM UTC-4, Brent Friedman 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">Evan,<div><br></div><div>Yes =
that does address the issue I was raising. Of course, if strings and vector=
s used pointer iterators then we wouldn&#39;t need the if test or the overl=
oad at all.</div></div></blockquote><div><br>Even if those two types use po=
inter iterators, that shouldn&#39;t mean that contiguous iterators <i>ought=
</i> to be pointers. What about range adaptors? Some of those can be contig=
uous iterators, but they&#39;re certainly not pointers.<br><br>Of course, y=
ou wouldn&#39;t be able to use range adaptors in string_views either. They&=
#39;re more for template code. So there&#39;s another strike against this o=
verload. `string_view` is meant for arrays of characters, which in C++ is s=
pecified by pointers.<br><br>Ultimately, what you want isn&#39;t for std::s=
tring and std::vector iterators to be pointers. You want them to be <i>conv=
ertible</i> to pointers (and vice-versa).</div></div></blockquote></div></d=
iv>

<p></p>

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

------=_Part_616_1178035029.1446138462553--
------=_Part_615_2098889785.1446138462540--

.

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

On Thu, Oct 29, 2015 at 12:24 PM, Brent Friedman <fourthgeek@gmail.com>
wrote:

> Evan,
>
> Yes that does address the issue I was raising. Of course, if strings and
> vectors used pointer iterators then we wouldn't need the if test or the
> overload at all.
>
> I think this constructor has a lot of room to be accidentally abused,
> however.
>
> One way to work around this is with a "make_*" style utility that uses
> domain knowledge to convert iterators. For example,
>
> string_view make_string_view(array<char>::iterator b,
> array<char>::iterator e);
> string_view make_string_view(vector<char>::iterator b,
> vector<char>::iterator e);
> string_view make_string_view(string::iterator b, string::iterator e);
>

Just note that array<char>::iterator may be char *, and so might
vector<char>::iterator, and string::iterator.
So is that 3 function declarations or 1?


>
> You can then overload make_string_view to support your own iterator types
> if you know that they are contiguous.
>
> I'll also point out that contiguous iterators are not sufficient; begin
> must also be less than end from the perspective of its underlying memory
> location. IE, it doesn't work with reverse_iterator (and cannot be made to).
>
> On Thu, Oct 29, 2015 at 10:56 AM, Evan Teran <evan.teran@gmail.com> wrote:
>
>> @Bengt,
>>
>> So I think the part that Brent was objecting to was the unconditional "s_
>> = &*first;" in the initial version. The concern being the deference then
>> reference of end() if given string_view(end(), end()); But as shown,
>> this is trivially worked around.
>>
>> I agree about your assessment of the iterators. And I also thought it was
>> important to insist that the iterators be rand access for a couple of
>> reasons:
>>
>> 1. std::distance would be O(1)
>> 2. last would have to be not a sentinel (I think a sentinel is
>> incompatible with being a random access, right?)
>>
>> We could simplify the constructor slightly like this:
>>
>> template <class Ran>
>> string_view(Ran first, Ran last) {
>>     n_ = distance(first, last);
>>     if(n_ != 0) {
>>         s_ = &*first;
>>     } else {
>>         s_ = nullptr;
>>     }
>> }
>>
>> Then we don't need to directly compare the iterators, we only care if
>> there is any distance between them. Thus avoiding the bizarre case of
>> iterators that are equal but have a distance. (which is honestly evil, i
>> hope no one does that)
>>
>>
>> On Thursday, October 29, 2015 at 11:44:03 AM UTC-4, Bengt Gustafsson
>> wrote:
>>>
>>>
>>>
>>>> string_view(end(), end()) should create a legal string_view, but
>>>> dereferencing end as in the given implementation is UB.
>>>>
>>>> Enlighten me: I don't see what the problem is here. The created
>>> string_view has two equal iterators so n_ would be 0. Of course it is not
>>> allowed to dereference the object using for instance operator[] but
>>> that's always true of an empty string_view, isn't it?
>>>
>>> The only thing the "solution" that Even suggests changes is that the
>>> subtraction of two equal iterators is replaced with a != test. I can't see
>>> that this could be a problem for an iterator type that has operator-
>>> defined. That would mean that
>>> there would be iterator values that compare equal but don't return 0
>>> when subtracted from each other. That's bizarre (even though it is possible
>>> to construct such classes of course, with (im)proper overloads). I see the
>>> problem for non-random access iterators where one can be some kind of
>>> sentinel, but then operator- is not defined anyway... and typically the
>>> iterator type for the ends are different which is not supported in the
>>> suggested API.
>>>
>>>
>>>>
>>>> On Thu, Oct 29, 2015 at 2:02 AM, 'Jeffrey Yasskin' via ISO C++ Standard
>>>> - Future Proposals <std-pr...@isocpp.org> wrote:
>>>>
>>>>> We need to be able to identify "contiguous" iterators in order to
>>>>> accept iterators in string_view's constructor. otherwise, ((&*first) +
>>>>> distance(first, last) - 1) might not be equal to &*(last-1).
>>>>>
>>>>> On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran <evan....@gmail.com>
>>>>> wrote:
>>>>> > I was just looking at the fine details of string_view. And it
>>>>> occurred to me
>>>>> > that being able to construct one from an iterator pair might make
>>>>> sense.
>>>>> > Assuming that the string_view internally just stores a Ch* and a
>>>>> size_type
>>>>> > pair. I *think* it could be defined like this:
>>>>> >
>>>>> > template <class Ran>
>>>>> > string_view(Ran first, Ran last) {
>>>>> >     s_ = &*first;
>>>>> >     n_ = distance(first, last);
>>>>> > }
>>>>> >
>>>>> > or something similar. At first glance, this seems like it would be
>>>>> useful.
>>>>> > Often algorithms which we would use to find a portion of the string
>>>>> will
>>>>> > return an iterator. Which could then be fed into string_view
>>>>> directly :-)
>>>>> >
>>>>> > Is there any reason not to support this? Is there something obvious
>>>>> I'm
>>>>> > missing? I suppose we could always manually do this and use the
>>>>> > string_view(const Ch*, size_type) constructor. But I think accepting
>>>>> > iterators directly would make for cleaner, more readable code.
>>>>> >
>>>>> > --
>>>>> >
>>>>> > ---
>>>>> > 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/.
>>>>>
>>>>> --
>>>>>
>>>>> ---
>>>>> 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/.
>>>>>
>>>>
>>>> --
>>
>> ---
>> 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/.
>

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Oct 29, 2015 at 12:24 PM, Brent Friedman <span dir=3D"ltr">&lt;=
<a href=3D"mailto:fourthgeek@gmail.com" target=3D"_blank">fourthgeek@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">Evan,<div><br></div><div>Yes that does address the issue I was raising. O=
f course, if strings and vectors used pointer iterators then we wouldn&#39;=
t need the if test or the overload at all.</div><div><br></div><div>I think=
 this constructor has a lot of room to be accidentally abused, however.</di=
v><div><br></div><div>One way to work around this is with a &quot;make_*&qu=
ot; style utility that uses domain knowledge to convert iterators. For exam=
ple,</div><div><br></div><div>string_view make_string_view(array&lt;char&gt=
;::iterator b, array&lt;char&gt;::iterator e);</div><div>string_view make_s=
tring_view(vector&lt;char&gt;::iterator b, vector&lt;char&gt;::iterator e);=
</div><div>string_view make_string_view(string::iterator b, string::iterato=
r e);</div></div></blockquote><div><br></div><div>Just note that array&lt;c=
har&gt;::iterator may be char *, and so might vector&lt;char&gt;::iterator,=
 and string::iterator.<br></div><div>So is that 3 function declarations or =
1?<br>=C2=A0<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"><div>=
<br></div><div>You can then overload make_string_view to support your own i=
terator types if you know that they are contiguous.</div><div><br></div><di=
v>I&#39;ll also point out that contiguous iterators are not sufficient; beg=
in must also be less than end from the perspective of its underlying memory=
 location. IE, it doesn&#39;t work with reverse_iterator (and cannot be mad=
e to).</div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Thu, Oct 29, 2015 at 10:56 AM, =
Evan Teran <span dir=3D"ltr">&lt;<a href=3D"mailto:evan.teran@gmail.com" ta=
rget=3D"_blank">evan.teran@gmail.com</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">@Bengt,<div><br></div><div>So I think th=
e part that Brent was objecting to w<font color=3D"#000000">as the uncondit=
ional <font face=3D"courier new, monospace">&quot;s_ =3D &amp;*first;</font=
>&quot; in the initial version. The concern being the=C2=A0deference=C2=A0t=
hen reference of <font face=3D"courier new, monospace">end()</font> if give=
n <font face=3D"courier new, monospace">string_view(end(), end());</font><f=
ont face=3D"arial, sans-serif">=C2=A0But as shown, this is trivially worked=
 around.</font></font></div><div><font face=3D"arial, sans-serif" color=3D"=
#000000"><br></font></div><div><font face=3D"arial, sans-serif" color=3D"#0=
00000">I agree about your assessment of the iterators. And I also thought i=
t was important to insist that the iterators be rand access for a couple of=
 reasons:</font></div><div><font face=3D"arial, sans-serif" color=3D"#00000=
0"><br></font></div><div><font face=3D"arial, sans-serif" color=3D"#000000"=
>1. </font><font face=3D"courier new, monospace" color=3D"#000000">std::dis=
tance</font><font face=3D"arial, sans-serif" color=3D"#000000"> would be O(=
1)</font></div><div><font face=3D"arial, sans-serif" color=3D"#000000">2. <=
/font><font face=3D"courier new, monospace" color=3D"#000000">last</font><f=
ont face=3D"arial, sans-serif" color=3D"#000000"> would have to be not a=C2=
=A0</font><span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif">sen=
tinel=C2=A0</span><font face=3D"arial, sans-serif" color=3D"#000000">(I thi=
nk a sentinel is incompatible with being a random access, right?)</font></d=
iv><div><font face=3D"arial, sans-serif" color=3D"#000000"><br></font></div=
><div><font face=3D"arial, sans-serif" color=3D"#000000">We could simplify =
the constructor slightly like this:</font></div><div><font face=3D"arial, s=
ans-serif" color=3D"#000000"><br></font></div><div><div><span><div><font fa=
ce=3D"courier new, monospace" color=3D"#000000">template &lt;class Ran&gt;<=
/font></div><div><font face=3D"courier new, monospace" color=3D"#000000">st=
ring_view(Ran first, Ran last) {</font></div></span><div><font face=3D"cour=
ier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 n_ =3D distance(first, =
last);</font></div></div><div><font face=3D"courier new, monospace" color=
=3D"#000000">=C2=A0 =C2=A0 if(n_ !=3D 0) {</font></div><div><div><font face=
=3D"courier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 s=
_ =3D &amp;*first; =C2=A0 =C2=A0 =C2=A0 =C2=A0</font></div></div><div><font=
 face=3D"courier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 } else {</=
font></div><div><font face=3D"courier new, monospace" color=3D"#000000">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 s_ =3D nullptr;</font></div><div><font face=3D"cou=
rier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 }</font></div><div><fo=
nt face=3D"courier new, monospace" color=3D"#000000">}</font></div><div><fo=
nt face=3D"courier new, monospace" color=3D"#000000"><br></font></div><div>=
<font face=3D"arial, sans-serif" color=3D"#000000">Then we don&#39;t need t=
o directly compare the iterators, we only care if there is any distance bet=
ween them. Thus avoiding the bizarre case of iterators that are equal but h=
ave a distance. (which is honestly evil, i hope no one does that)</font></d=
iv><br><br></div><div><div><div>On Thursday, October 29, 2015 at 11:44:03 A=
M UTC-4, Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><br></div><div><div>string_view(end(), end()) should create a legal st=
ring_view, but dereferencing end as in the given implementation is UB.</div=
><div><br></div></div></div></blockquote><div>Enlighten me: I don&#39;t see=
 what the problem is here. The created string_view has two equal iterators =
so n_ would be 0. Of course it is not allowed to dereference the object usi=
ng for instance operator[] but</div><div>that&#39;s always true of an empty=
 string_view, isn&#39;t it?</div><div><br></div><div>The only thing the &qu=
ot;solution&quot; that Even suggests changes is that the subtraction of two=
 equal iterators is replaced with a !=3D test. I can&#39;t see that this co=
uld be a problem for an iterator type that has operator- defined. That woul=
d mean that</div><div>there would be iterator values that compare equal but=
 don&#39;t return 0 when subtracted from each other. That&#39;s bizarre (ev=
en though it is possible to construct such classes of course, with (im)prop=
er overloads). I see the problem for non-random access iterators where one =
can be some kind of sentinel, but then operator- is not defined anyway... a=
nd typically the iterator type for the ends are different which is not supp=
orted in the suggested API.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div></div></div></div><div><br><div c=
lass=3D"gmail_quote">On Thu, Oct 29, 2015 at 2:02 AM, &#39;Jeffrey Yasskin&=
#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">std-pr...@isocpp.org</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">We need to be able to identify &quot;contiguous&quot; itera=
tors in order to<br>
accept iterators in string_view&#39;s constructor. otherwise, ((&amp;*first=
) +<br>
distance(first, last) - 1) might not be equal to &amp;*(last-1).<br>
<div><div><br>
On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran &lt;<a rel=3D"nofollow">evan...=
..@gmail.com</a>&gt; wrote:<br>
&gt; I was just looking at the fine details of string_view. And it occurred=
 to me<br>
&gt; that being able to construct one from an iterator pair might make sens=
e.<br>
&gt; Assuming that the string_view internally just stores a Ch* and a size_=
type<br>
&gt; pair. I *think* it could be defined like this:<br>
&gt;<br>
&gt; template &lt;class Ran&gt;<br>
&gt; string_view(Ran first, Ran last) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0s_ =3D &amp;*first;<br>
&gt;=C2=A0 =C2=A0 =C2=A0n_ =3D distance(first, last);<br>
&gt; }<br>
&gt;<br>
&gt; or something similar. At first glance, this seems like it would be use=
ful.<br>
&gt; Often algorithms which we would use to find a portion of the string wi=
ll<br>
&gt; return an iterator. Which could then be fed into string_view directly =
:-)<br>
&gt;<br>
&gt; Is there any reason not to support this? Is there something obvious I&=
#39;m<br>
&gt; missing? I suppose we could always manually do this and use the<br>
&gt; string_view(const Ch*, size_type) constructor. But I think accepting<b=
r>
&gt; iterators directly would make for cleaner, more readable code.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 rel=3D"nofollow" target=3D"_blank">http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></blockquote></div></div></div></div><div><div>

<p></p>

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

--001a11c377a2524039052341777c--

.

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

>
> Just note that array<char>::iterator may be char *, and so might
> vector<char>::iterator, and string::iterator.
> So is that 3 function declarations or 1?
>

Yep, you're right. This is another reason why I think the iterators should
be pointers. It makes cross-plat development awful.

But I don't want to take this thread too far off-topic.

On Thu, Oct 29, 2015 at 12:16 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Thu, Oct 29, 2015 at 12:24 PM, Brent Friedman <fourthgeek@gmail.com>
> wrote:
>
>> Evan,
>>
>> Yes that does address the issue I was raising. Of course, if strings and
>> vectors used pointer iterators then we wouldn't need the if test or the
>> overload at all.
>>
>> I think this constructor has a lot of room to be accidentally abused,
>> however.
>>
>> One way to work around this is with a "make_*" style utility that uses
>> domain knowledge to convert iterators. For example,
>>
>> string_view make_string_view(array<char>::iterator b,
>> array<char>::iterator e);
>> string_view make_string_view(vector<char>::iterator b,
>> vector<char>::iterator e);
>> string_view make_string_view(string::iterator b, string::iterator e);
>>
>
> Just note that array<char>::iterator may be char *, and so might
> vector<char>::iterator, and string::iterator.
> So is that 3 function declarations or 1?
>
>
>>
>> You can then overload make_string_view to support your own iterator types
>> if you know that they are contiguous.
>>
>> I'll also point out that contiguous iterators are not sufficient; begin
>> must also be less than end from the perspective of its underlying memory
>> location. IE, it doesn't work with reverse_iterator (and cannot be made to).
>>
>> On Thu, Oct 29, 2015 at 10:56 AM, Evan Teran <evan.teran@gmail.com>
>> wrote:
>>
>>> @Bengt,
>>>
>>> So I think the part that Brent was objecting to was the unconditional "s_
>>> = &*first;" in the initial version. The concern being
>>> the deference then reference of end() if given string_view(end(),
>>> end()); But as shown, this is trivially worked around.
>>>
>>> I agree about your assessment of the iterators. And I also thought it
>>> was important to insist that the iterators be rand access for a couple of
>>> reasons:
>>>
>>> 1. std::distance would be O(1)
>>> 2. last would have to be not a sentinel (I think a sentinel is
>>> incompatible with being a random access, right?)
>>>
>>> We could simplify the constructor slightly like this:
>>>
>>> template <class Ran>
>>> string_view(Ran first, Ran last) {
>>>     n_ = distance(first, last);
>>>     if(n_ != 0) {
>>>         s_ = &*first;
>>>     } else {
>>>         s_ = nullptr;
>>>     }
>>> }
>>>
>>> Then we don't need to directly compare the iterators, we only care if
>>> there is any distance between them. Thus avoiding the bizarre case of
>>> iterators that are equal but have a distance. (which is honestly evil, i
>>> hope no one does that)
>>>
>>>
>>> On Thursday, October 29, 2015 at 11:44:03 AM UTC-4, Bengt Gustafsson
>>> wrote:
>>>>
>>>>
>>>>
>>>>> string_view(end(), end()) should create a legal string_view, but
>>>>> dereferencing end as in the given implementation is UB.
>>>>>
>>>>> Enlighten me: I don't see what the problem is here. The created
>>>> string_view has two equal iterators so n_ would be 0. Of course it is not
>>>> allowed to dereference the object using for instance operator[] but
>>>> that's always true of an empty string_view, isn't it?
>>>>
>>>> The only thing the "solution" that Even suggests changes is that the
>>>> subtraction of two equal iterators is replaced with a != test. I can't see
>>>> that this could be a problem for an iterator type that has operator-
>>>> defined. That would mean that
>>>> there would be iterator values that compare equal but don't return 0
>>>> when subtracted from each other. That's bizarre (even though it is possible
>>>> to construct such classes of course, with (im)proper overloads). I see the
>>>> problem for non-random access iterators where one can be some kind of
>>>> sentinel, but then operator- is not defined anyway... and typically the
>>>> iterator type for the ends are different which is not supported in the
>>>> suggested API.
>>>>
>>>>
>>>>>
>>>>> On Thu, Oct 29, 2015 at 2:02 AM, 'Jeffrey Yasskin' via ISO C++
>>>>> Standard - Future Proposals <std-pr...@isocpp.org> wrote:
>>>>>
>>>>>> We need to be able to identify "contiguous" iterators in order to
>>>>>> accept iterators in string_view's constructor. otherwise, ((&*first) +
>>>>>> distance(first, last) - 1) might not be equal to &*(last-1).
>>>>>>
>>>>>> On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran <evan....@gmail.com>
>>>>>> wrote:
>>>>>> > I was just looking at the fine details of string_view. And it
>>>>>> occurred to me
>>>>>> > that being able to construct one from an iterator pair might make
>>>>>> sense.
>>>>>> > Assuming that the string_view internally just stores a Ch* and a
>>>>>> size_type
>>>>>> > pair. I *think* it could be defined like this:
>>>>>> >
>>>>>> > template <class Ran>
>>>>>> > string_view(Ran first, Ran last) {
>>>>>> >     s_ = &*first;
>>>>>> >     n_ = distance(first, last);
>>>>>> > }
>>>>>> >
>>>>>> > or something similar. At first glance, this seems like it would be
>>>>>> useful.
>>>>>> > Often algorithms which we would use to find a portion of the string
>>>>>> will
>>>>>> > return an iterator. Which could then be fed into string_view
>>>>>> directly :-)
>>>>>> >
>>>>>> > Is there any reason not to support this? Is there something obvious
>>>>>> I'm
>>>>>> > missing? I suppose we could always manually do this and use the
>>>>>> > string_view(const Ch*, size_type) constructor. But I think accepting
>>>>>> > iterators directly would make for cleaner, more readable code.
>>>>>> >
>>>>>> > --
>>>>>> >
>>>>>> > ---
>>>>>> > 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/.
>>>>>>
>>>>>> --
>>>>>>
>>>>>> ---
>>>>>> 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/.
>>>>>>
>>>>>
>>>>> --
>>>
>>> ---
>>> 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/.
>>
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr"><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-l=
eft-style:solid;padding-left:1ex"><div style=3D"font-size:12.8px">Just note=
 that array&lt;char&gt;::iterator may be char *, and so might vector&lt;cha=
r&gt;::iterator, and string::iterator.<br></div><div style=3D"font-size:12.=
8px">So is that 3 function declarations or 1?</div></blockquote><div><br></=
div><div>Yep, you&#39;re right. This is another reason why I think the iter=
ators should be pointers. It makes cross-plat development awful.</div><div>=
<br></div><div>But I don&#39;t want to take this thread too far off-topic.=
=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Thu, Oct 29, 2015 at 12:16 PM, Tony V E <span dir=3D"ltr">&lt;<a href=
=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@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:1ex"><div dir=3D"ltr"><br><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Th=
u, Oct 29, 2015 at 12:24 PM, Brent Friedman <span dir=3D"ltr">&lt;<a href=
=3D"mailto:fourthgeek@gmail.com" target=3D"_blank">fourthgeek@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:1ex"><div dir=3D"ltr">Evan,=
<div><br></div><div>Yes that does address the issue I was raising. Of cours=
e, if strings and vectors used pointer iterators then we wouldn&#39;t need =
the if test or the overload at all.</div><div><br></div><div>I think this c=
onstructor has a lot of room to be accidentally abused, however.</div><div>=
<br></div><div>One way to work around this is with a &quot;make_*&quot; sty=
le utility that uses domain knowledge to convert iterators. For example,</d=
iv><div><br></div><div>string_view make_string_view(array&lt;char&gt;::iter=
ator b, array&lt;char&gt;::iterator e);</div><div>string_view make_string_v=
iew(vector&lt;char&gt;::iterator b, vector&lt;char&gt;::iterator e);</div><=
div>string_view make_string_view(string::iterator b, string::iterator e);</=
div></div></blockquote><div><br></div></span><div>Just note that array&lt;c=
har&gt;::iterator may be char *, and so might vector&lt;char&gt;::iterator,=
 and string::iterator.<br></div><div>So is that 3 function declarations or =
1?<br>=C2=A0<br></div><div><div class=3D"h5"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><br></div><div>You can then overload make_string_vie=
w to support your own iterator types if you know that they are contiguous.<=
/div><div><br></div><div>I&#39;ll also point out that contiguous iterators =
are not sufficient; begin must also be less than end from the perspective o=
f its underlying memory location. IE, it doesn&#39;t work with reverse_iter=
ator (and cannot be made to).</div></div><div><div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Thu, Oct 29, 2015 at 10:56 AM, Evan Te=
ran <span dir=3D"ltr">&lt;<a href=3D"mailto:evan.teran@gmail.com" target=3D=
"_blank">evan.teran@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:1ex"><div dir=3D"ltr">@Bengt,<div><br></div><div>So I think the part =
that Brent was objecting to w<font color=3D"#000000">as the unconditional <=
font face=3D"courier new, monospace">&quot;s_ =3D &amp;*first;</font>&quot;=
 in the initial version. The concern being the=C2=A0deference=C2=A0then ref=
erence of <font face=3D"courier new, monospace">end()</font> if given <font=
 face=3D"courier new, monospace">string_view(end(), end());</font><font fac=
e=3D"arial, sans-serif">=C2=A0But as shown, this is trivially worked around=
..</font></font></div><div><font face=3D"arial, sans-serif" color=3D"#000000=
"><br></font></div><div><font face=3D"arial, sans-serif" color=3D"#000000">=
I agree about your assessment of the iterators. And I also thought it was i=
mportant to insist that the iterators be rand access for a couple of reason=
s:</font></div><div><font face=3D"arial, sans-serif" color=3D"#000000"><br>=
</font></div><div><font face=3D"arial, sans-serif" color=3D"#000000">1. </f=
ont><font face=3D"courier new, monospace" color=3D"#000000">std::distance</=
font><font face=3D"arial, sans-serif" color=3D"#000000"> would be O(1)</fon=
t></div><div><font face=3D"arial, sans-serif" color=3D"#000000">2. </font><=
font face=3D"courier new, monospace" color=3D"#000000">last</font><font fac=
e=3D"arial, sans-serif" color=3D"#000000"> would have to be not a=C2=A0</fo=
nt><span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif">sentinel=
=C2=A0</span><font face=3D"arial, sans-serif" color=3D"#000000">(I think a =
sentinel is incompatible with being a random access, right?)</font></div><d=
iv><font face=3D"arial, sans-serif" color=3D"#000000"><br></font></div><div=
><font face=3D"arial, sans-serif" color=3D"#000000">We could simplify the c=
onstructor slightly like this:</font></div><div><font face=3D"arial, sans-s=
erif" color=3D"#000000"><br></font></div><div><div><span><div><font face=3D=
"courier new, monospace" color=3D"#000000">template &lt;class Ran&gt;</font=
></div><div><font face=3D"courier new, monospace" color=3D"#000000">string_=
view(Ran first, Ran last) {</font></div></span><div><font face=3D"courier n=
ew, monospace" color=3D"#000000">=C2=A0 =C2=A0 n_ =3D distance(first, last)=
;</font></div></div><div><font face=3D"courier new, monospace" color=3D"#00=
0000">=C2=A0 =C2=A0 if(n_ !=3D 0) {</font></div><div><div><font face=3D"cou=
rier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 s_ =3D &=
amp;*first; =C2=A0 =C2=A0 =C2=A0 =C2=A0</font></div></div><div><font face=
=3D"courier new, monospace" color=3D"#000000">=C2=A0 =C2=A0 } else {</font>=
</div><div><font face=3D"courier new, monospace" color=3D"#000000">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 s_ =3D nullptr;</font></div><div><font face=3D"courier=
 new, monospace" color=3D"#000000">=C2=A0 =C2=A0 }</font></div><div><font f=
ace=3D"courier new, monospace" color=3D"#000000">}</font></div><div><font f=
ace=3D"courier new, monospace" color=3D"#000000"><br></font></div><div><fon=
t face=3D"arial, sans-serif" color=3D"#000000">Then we don&#39;t need to di=
rectly compare the iterators, we only care if there is any distance between=
 them. Thus avoiding the bizarre case of iterators that are equal but have =
a distance. (which is honestly evil, i hope no one does that)</font></div><=
br><br></div><div><div><div>On Thursday, October 29, 2015 at 11:44:03 AM UT=
C-4, Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><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"><div=
><br></div><div><div>string_view(end(), end()) should create a legal string=
_view, but dereferencing end as in the given implementation is UB.</div><di=
v><br></div></div></div></blockquote><div>Enlighten me: I don&#39;t see wha=
t the problem is here. The created string_view has two equal iterators so n=
_ would be 0. Of course it is not allowed to dereference the object using f=
or instance operator[] but</div><div>that&#39;s always true of an empty str=
ing_view, isn&#39;t it?</div><div><br></div><div>The only thing the &quot;s=
olution&quot; that Even suggests changes is that the subtraction of two equ=
al iterators is replaced with a !=3D test. I can&#39;t see that this could =
be a problem for an iterator type that has operator- defined. That would me=
an that</div><div>there would be iterator values that compare equal but don=
&#39;t return 0 when subtracted from each other. That&#39;s bizarre (even t=
hough it is possible to construct such classes of course, with (im)proper o=
verloads). I see the problem for non-random access iterators where one can =
be some kind of sentinel, but then operator- is not defined anyway... and t=
ypically the iterator type for the ends are different which is not supporte=
d in the suggested API.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><div></div></div></div><div><br><div class=
=3D"gmail_quote">On Thu, Oct 29, 2015 at 2:02 AM, &#39;Jeffrey Yasskin&#39;=
 via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a rel=3D"no=
follow">std-pr...@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">We need to be able to identify &quot;contiguous&quot; iterators i=
n order to<br>
accept iterators in string_view&#39;s constructor. otherwise, ((&amp;*first=
) +<br>
distance(first, last) - 1) might not be equal to &amp;*(last-1).<br>
<div><div><br>
On Thu, Oct 29, 2015 at 3:24 PM, Evan Teran &lt;<a rel=3D"nofollow">evan...=
..@gmail.com</a>&gt; wrote:<br>
&gt; I was just looking at the fine details of string_view. And it occurred=
 to me<br>
&gt; that being able to construct one from an iterator pair might make sens=
e.<br>
&gt; Assuming that the string_view internally just stores a Ch* and a size_=
type<br>
&gt; pair. I *think* it could be defined like this:<br>
&gt;<br>
&gt; template &lt;class Ran&gt;<br>
&gt; string_view(Ran first, Ran last) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0s_ =3D &amp;*first;<br>
&gt;=C2=A0 =C2=A0 =C2=A0n_ =3D distance(first, last);<br>
&gt; }<br>
&gt;<br>
&gt; or something similar. At first glance, this seems like it would be use=
ful.<br>
&gt; Often algorithms which we would use to find a portion of the string wi=
ll<br>
&gt; return an iterator. Which could then be fed into string_view directly =
:-)<br>
&gt;<br>
&gt; Is there any reason not to support this? Is there something obvious I&=
#39;m<br>
&gt; missing? I suppose we could always manually do this and use the<br>
&gt; string_view(const Ch*, size_type) constructor. But I think accepting<b=
r>
&gt; iterators directly would make for cleaner, more readable code.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 rel=3D"nofollow" target=3D"_blank">http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></blockquote></div></div></div></div><div><div>

<p></p>

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

<p></p>

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

--e89a8ff1ccb4f2950d0523417d0c--

.

On 10/29/2015 06:16 PM, Tony V E wrote:
>
>
> On Thu, Oct 29, 2015 at 12:24 PM, Brent Friedman <fourthgeek@gmail.com
> <mailto:fourthgeek@gmail.com>> wrote:

>     One way to work around this is with a "make_*" style utility that
>     uses domain knowledge to convert iterators. For example,
>
>     string_view make_string_view(array<char>::iterator b,
>     array<char>::iterator e);
>     string_view make_string_view(vector<char>::iterator b,
>     vector<char>::iterator e);
>     string_view make_string_view(string::iterator b, string::iterator e);
>
>
> Just note that array<char>::iterator may be char *, and so might
> vector<char>::iterator, and string::iterator.
> So is that 3 function declarations or 1?

An alternative is to let the factory be part of a trait. Something like
this:

   template <typename T>
   struct string_view_trait {};

   template <typename CharT, size_t N>
   struct string_view_trait<std::array<CharT, N>>
   { static string_view make(std::array<CharT>::iterator,
std::array<CharT>::iterator); };

etc.

--

---
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_505_2104162654.1446491078216
Content-Type: multipart/alternative;
 boundary="----=_Part_506_1281187469.1446491078216"

------=_Part_506_1281187469.1446491078216
Content-Type: text/plain; charset=UTF-8



On Thursday, October 29, 2015 at 7:24:31 AM UTC+1, Evan Teran wrote:
>
> I was just looking at the fine details of string_view. And it occurred to
> me that being able to construct one from an iterator pair might make sense.
> Assuming that the string_view internally just stores a Ch* and a size_type
> pair. I *think* it could be defined like this:
>
> template <class Ran>
> string_view(Ran first, Ran last) {
>     s_ = &*first;
>     n_ = distance(first, last);
> }
>
> or something similar. At first glance, this seems like it would be useful.
> Often algorithms which we would use to find a portion of the string will
> return an iterator. Which could then be fed into string_view directly :-)
>
> Is there any reason not to support this? Is there something obvious I'm
> missing? I suppose we could always manually do this and use the
> string_view(const Ch*, size_type) constructor. But I think accepting
> iterators directly would make for cleaner, more readable code.
>

How often do you use iterators with strings? Note that strings member
functions mostly are index-based.

--

---
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_506_1281187469.1446491078216
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, October 29, 2015 at 7:24:31 AM UTC+1, Evan Teran wrote=
:<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">I was just l=
ooking at the fine details of string_view. And it occurred to me that being=
 able to construct one from an iterator pair might make sense. Assuming tha=
t the string_view internally just stores a Ch* and a size_type pair. I *thi=
nk* it could be defined like this:<div><br></div><div>template &lt;class Ra=
n&gt;</div><div>string_view(Ran first, Ran last) {</div><div>=C2=A0 =C2=A0 =
s_ =3D &amp;*first;</div><div>=C2=A0 =C2=A0 n_ =3D distance(first, last);</=
div><div>}</div><div><br></div><div>or something similar. At first glance, =
this seems like it would be useful. Often algorithms which we would use to =
find a portion of the string will return an iterator. Which could then be f=
ed into string_view directly :-)</div><div><br></div><div>Is there any reas=
on not to support this? Is there something obvious I&#39;m missing? I suppo=
se we could always manually do this and use the string_view(const Ch*, size=
_type) constructor. But I think accepting iterators directly would make for=
 cleaner, more readable code.</div></div></blockquote><div><br></div><div>H=
ow often do you use iterators with strings? Note that strings member functi=
ons mostly are index-based.=C2=A0</div>

<p></p>

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

------=_Part_506_1281187469.1446491078216--
------=_Part_505_2104162654.1446491078216--

.

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

On 2 November 2015 at 13:04, Olaf van der Spek <olafvdspek@gmail.com> wrote:

>
> How often do you use iterators with strings?
>

Very.  Basically, any time I apply an algorithm to them, especially
predicates such as the ones found in the Boost String Algorithms Library
<http://www.boost.org/doc/libs/1_59_0/doc/html/string_algo.html>.
--
 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/.

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

<div dir=3D"ltr">On 2 November 2015 at 13:04, Olaf van der Spek <span dir=
=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olaf=
vdspek@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div><=
br></div></span><div>How often do you use iterators with strings? </div></b=
lockquote><div><br></div><div>Very.=C2=A0 Basically, any time I apply an al=
gorithm to them, especially predicates such as the ones found in the <a hre=
f=3D"http://www.boost.org/doc/libs/1_59_0/doc/html/string_algo.html">Boost =
String Algorithms Library</a>.</div></div>-- <br><div class=3D"gmail_signat=
ure">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=
=A0 (847) 691-1404</div>
</div></div>

<p></p>

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

--001a113da7d2eacbbf052393814d--

.

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

Any time you have an iterator,  you can have a char*,  and that it also
assuming that the Ran is contiguous,  which it isn't garunteed to be.

On Mon, Nov 2, 2015, 12:08 PM Nevin Liber <nevin@eviloverlord.com> wrote:

> On 2 November 2015 at 13:04, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
>
>>
>> How often do you use iterators with strings?
>>
>
> Very.  Basically, any time I apply an algorithm to them, especially
> predicates such as the ones found in the Boost String Algorithms Library
> <http://www.boost.org/doc/libs/1_59_0/doc/html/string_algo.html>.
> --
>  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/.

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

<p dir=3D"ltr">Any time you have an iterator,=C2=A0 you can have a char*,=
=C2=A0 and that it also assuming that the Ran is contiguous,=C2=A0 which it=
 isn&#39;t garunteed to be. </p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Nov 2, 2015, 12:08 =
PM=C2=A0Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.com">nevin@evi=
loverlord.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">On 2 November 2015 at 13:04, Olaf van der Spek <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@g=
mail.com</a>&gt;</span> wrote:<br></div><div dir=3D"ltr"><div class=3D"gmai=
l_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"><span><d=
iv><br></div></span><div>How often do you use iterators with strings? </div=
></blockquote><div><br></div></div></div></div><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>Very.=C2=A0 Basically, any=
 time I apply an algorithm to them, especially predicates such as the ones =
found in the <a href=3D"http://www.boost.org/doc/libs/1_59_0/doc/html/strin=
g_algo.html" target=3D"_blank">Boost String Algorithms Library</a>.</div></=
div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra">-- <br><div>=C2=
=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847)=
 691-1404</div>
</div></div>

<p></p>

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

--e89a8fb200c64ef9e60523957a2d--

.

------=_Part_987_1398302942.1446500009082
Content-Type: multipart/alternative;
 boundary="----=_Part_988_1923778611.1446500009083"

------=_Part_988_1923778611.1446500009083
Content-Type: text/plain; charset=UTF-8

Sure, you can always convert a std::string::iterator to a char* using
something like &*it, but why require the extra syntax just to say "starting
here". An iterator already represents the concept of "here".

On Monday, November 2, 2015 at 4:29:55 PM UTC-5, Russell Greene wrote:
>
> Any time you have an iterator,  you can have a char*,  and that it also
> assuming that the Ran is contiguous,  which it isn't garunteed to be.
>
> On Mon, Nov 2, 2015, 12:08 PM Nevin Liber <ne...@eviloverlord.com
> <javascript:>> wrote:
>
>> On 2 November 2015 at 13:04, Olaf van der Spek <olafv...@gmail.com
>> <javascript:>> wrote:
>>
>>>
>>> How often do you use iterators with strings?
>>>
>>
>> Very.  Basically, any time I apply an algorithm to them, especially
>> predicates such as the ones found in the Boost String Algorithms Library
>> <http://www.boost.org/doc/libs/1_59_0/doc/html/string_algo.html>.
>> --
>>  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-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_988_1923778611.1446500009083
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Sure, you can always convert a std::string::iterator =
to a char* using something like &amp;*it, but why require the extra syntax =
just to say &quot;starting here&quot;. An iterator already represents the c=
oncept of &quot;here&quot;.<br><br>On Monday, November 2, 2015 at 4:29:55 P=
M UTC-5, Russell Greene wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<p dir=3D"ltr">Any time you have an iterator,=C2=A0 you can have a char*,=
=C2=A0 and that it also assuming that the Ran is contiguous,=C2=A0 which it=
 isn&#39;t garunteed to be. </p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Nov 2, 2015, 12:08 =
PM=C2=A0Nevin Liber &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"vnmuZLuEFAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">ne...@eviloverlord.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr">On 2 November 2015 at 13:04, Olaf va=
n der Spek <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"vnmuZLuEFAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">olafv...@gmail.com</a>&gt;</span> wrote:<br></d=
iv><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span><div><br></div></span><div>How often do you use iterators wit=
h strings? </div></blockquote><div><br></div></div></div></div><div dir=3D"=
ltr"><div><div class=3D"gmail_quote"><div>Very.=C2=A0 Basically, any time I=
 apply an algorithm to them, especially predicates such as the ones found i=
n the <a href=3D"http://www.boost.org/doc/libs/1_59_0/doc/html/string_algo.=
html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_59_=
0%2Fdoc%2Fhtml%2Fstring_algo.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHBwy2z=
XZgtkRLU5VQwwJZ3iN-oBA&#39;;return true;" onclick=3D"this.href=3D&#39;http:=
//www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_59_0%2=
Fdoc%2Fhtml%2Fstring_algo.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHBwy2zXZg=
tkRLU5VQwwJZ3iN-oBA&#39;;return true;">Boost String Algorithms Library</a>.=
</div></div></div></div><div dir=3D"ltr"><div>-- <br><div>=C2=A0Nevin &quot=
;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"vnmuZLuEFAAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">ne...@eviloverlord.com</a><wbr>&gt;=C2=A0 (847=
) 691-1404</div>
</div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
vnmuZLuEFAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">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"vnmuZLuEFAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">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" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>
</blockquote></div></div>

<p></p>

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

------=_Part_988_1923778611.1446500009083--
------=_Part_987_1398302942.1446500009082--

.

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

On 2 November 2015 at 15:29, Russell Greene <russellgreene8@gmail.com>
wrote:

> Any time you have an iterator,  you can have a char*,  and that it also
> assuming that the Ran is contiguous,  which it isn't garunteed to be.
>

How is that situation different that having two contiguous iterators
pointing into two different collections?  I'm not sure what you are
pointing out...
--
 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/.

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

<div dir=3D"ltr">On 2 November 2015 at 15:29, Russell Greene <span dir=3D"l=
tr">&lt;<a href=3D"mailto:russellgreene8@gmail.com" target=3D"_blank">russe=
llgreene8@gmail.com</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:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Any t=
ime you have an iterator,=C2=A0 you can have a char*,=C2=A0 and that it als=
o assuming that the Ran is contiguous,=C2=A0 which it isn&#39;t garunteed t=
o be.</p></blockquote><div><br></div><div>How is that situation different t=
hat having two contiguous iterators pointing into two different collections=
?=C2=A0 I&#39;m not sure what you are pointing out...</div></div>-- <br><di=
v class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mai=
lto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilo=
verlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

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

--001a11c0130050f12f0523959592--

.