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

On 29 October 2015 at 12:27, Nicol Bolas <jmckesson@gmail.com> wrote:

> That's the question: should the standard explicitly *require* that
> `basic_string`, `vector`, and `array` iterators are pointers?
>

No.

Oh, and don't forget valarray.

The contiguous iterator trait proposal has a way to convert from a
contiguous iterator to a pointer that LEWG likes.  Unfortunately, Real
Life(TM) has gotten in the way of me doing the next revision of it, and
coming up with the standardese for it isn't easy...
--
 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/.

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

<div dir=3D"ltr">On 29 October 2015 at 12:27, Nicol Bolas <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gma=
il.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">That&#39;s the q=
uestion: should the standard explicitly <i>require</i> that `basic_string`,=
 `vector`, and `array` iterators are pointers? </div></blockquote><div><br>=
</div><div>No.</div><div><br></div><div>Oh, and don&#39;t forget valarray.<=
/div><div><br></div><div>The contiguous iterator trait proposal has a way t=
o convert from a contiguous iterator to a pointer that LEWG likes.=C2=A0 Un=
fortunately, Real Life(TM) has gotten in the way of me doing the next revis=
ion of it, and coming up with the standardese for it isn&#39;t easy...<br><=
/div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot=
; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

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

--001a11c0130012dbda052341e347--

.

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

See Nevin's contiguous iterator proposal
www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4183.pdf


On Thu, Oct 29, 2015 at 1:27 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> That's the question: should the standard explicitly *require* that
> `basic_string`, `vector`, and `array` iterators are pointers? Along with
> any similar types we get (there's been some talk about `stack_array` or
> whatever).
>
> Let's break down the use cases. That is, why do we want them to be
> pointers?
>
> 1) Performance.
>
> 2) The ability to use such iterators in pointer-based interfaces without
> having to do `&*` on them.
>
> 3) The ability to get pointers back from pointer-based interfaces and use
> them easily.
>
> I've always felt that #1 should always be considered a question of the
> implementation. I *want* the ability for debug builds to be able to do
> range checking for me. I also want those checks to vanish in release builds.
>
> But I think we can achieve #2 and #3 without needing to make them
> explicitly pointers. We simply need two changes:
>
> A) Allow these iterators of these types to be *implicitly convertible* to
> pointers. That solves #2 neatly.
>
> B) Allow users to convert a pointer to some element into an iterator. That
> solves #3 neatly.
>
> B should be a (possibly non-member) function of the *container*. That is,
> you shouldn't be able to implicitly construct an iterator from a pointer.
> The container ought to verify that the pointer is actually within the range
> before doing so. And as a non-member function, it can be specialized/ADL'd
> for different types.
>
> Are these good ideas?
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">See Nevin&#39;s contiguous iterator proposal <cite class=
=3D""><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4=
183.pdf">www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4183.pdf</a><br>=
<br></cite></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Oct 29, 2015 at 1:27 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</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">That&#3=
9;s the question: should the standard explicitly <i>require</i> that `basic=
_string`, `vector`, and `array` iterators are pointers? Along with any simi=
lar types we get (there&#39;s been some talk about `stack_array` or whateve=
r).<br><br>Let&#39;s break down the use cases. That is, why do we want them=
 to be pointers?<br><br>1) Performance.<br><br>2) The ability to use such i=
terators in pointer-based interfaces without having to do `&amp;*` on them.=
<br><br>3) The ability to get pointers back from pointer-based interfaces a=
nd use them easily.<br><br>I&#39;ve always felt that #1 should always be co=
nsidered a question of the implementation. I <i>want</i> the ability for de=
bug builds to be able to do range checking for me. I also want those checks=
 to vanish in release builds.<br><br>But I think we can achieve #2 and #3 w=
ithout needing to make them explicitly pointers. We simply need two changes=
:<br><br>A) Allow these iterators of these types to be <i>implicitly conver=
tible</i> to pointers. That solves #2 neatly.<br><br>B) Allow users to conv=
ert a pointer to some element into an iterator. That solves #3 neatly.<br><=
br>B should be a (possibly non-member) function of the <i>container</i>. Th=
at is, you shouldn&#39;t be able to implicitly construct an iterator from a=
 pointer. The container ought to verify that the pointer is actually within=
 the range before doing so. And as a non-member function, it can be special=
ized/ADL&#39;d for different types.<br><br>Are these good ideas?<span class=
=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div><span class=3D"=
HOEnZb"><font color=3D"#888888">

<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>
</font></span></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 />

--089e011605f4b03ce2052341e4ee--

.

As a side use case, I wish I could have our simd::allocator returns
aligned_ptr (pointer like class that asserts on alignment constraints
beign violated) and have vector<T,simd::allocator<T>>::pointer be such
aligned_ptr.

I'm all in favor of such relaxation if it's not relaxed already

On 29/10/2015 18:45, Nevin Liber wrote:
> On 29 October 2015 at 12:27, Nicol Bolas <jmckesson@gmail.com
> <mailto:jmckesson@gmail.com>> wrote:
>
>     That's the question: should the standard explicitly /require/ that
>     `basic_string`, `vector`, and `array` iterators are pointers?
>
>
> No.
>
> Oh, and don't forget valarray.
>
> The contiguous iterator trait proposal has a way to convert from a
> contiguous iterator to a pointer that LEWG likes.  Unfortunately, Real
> Life(TM) has gotten in the way of me doing the next revision of it, and
> coming up with the standardese for it isn't easy...
> --
>   Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com
> <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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

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

.

------=_Part_138_680252009.1446177120188
Content-Type: multipart/alternative;
 boundary="----=_Part_139_193781386.1446177120188"

------=_Part_139_193781386.1446177120188
Content-Type: text/plain; charset=UTF-8

I think that the correct implementation could get the same performance in a
wrapper class then a raw pointer. This also gives the advantage as possible
checking in debug builds. Is there any particular scenario which raw
pointers would be better?

On Thursday, October 29, 2015 at 11:27:51 AM UTC-6, Nicol Bolas wrote:
>
> That's the question: should the standard explicitly *require* that
> `basic_string`, `vector`, and `array` iterators are pointers? Along with
> any similar types we get (there's been some talk about `stack_array` or
> whatever).
>
> Let's break down the use cases. That is, why do we want them to be
> pointers?
>
> 1) Performance.
>
> 2) The ability to use such iterators in pointer-based interfaces without
> having to do `&*` on them.
>
> 3) The ability to get pointers back from pointer-based interfaces and use
> them easily.
>
> I've always felt that #1 should always be considered a question of the
> implementation. I *want* the ability for debug builds to be able to do
> range checking for me. I also want those checks to vanish in release builds.
>
> But I think we can achieve #2 and #3 without needing to make them
> explicitly pointers. We simply need two changes:
>
> A) Allow these iterators of these types to be *implicitly convertible* to
> pointers. That solves #2 neatly.
>
> B) Allow users to convert a pointer to some element into an iterator. That
> solves #3 neatly.
>
> B should be a (possibly non-member) function of the *container*. That is,
> you shouldn't be able to implicitly construct an iterator from a pointer.
> The container ought to verify that the pointer is actually within the range
> before doing so. And as a non-member function, it can be specialized/ADL'd
> for different types.
>
> Are these good ideas?
>

--

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

<div dir=3D"ltr">I think that the correct implementation could get the same=
 performance in a wrapper class then a raw pointer. This also gives the adv=
antage as possible checking in debug builds. Is there any particular scenar=
io which raw pointers would be better?<br><br>On Thursday, October 29, 2015=
 at 11:27:51 AM UTC-6, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">That&#39;s the question: should the standard ex=
plicitly <i>require</i> that `basic_string`, `vector`, and `array` iterator=
s are pointers? Along with any similar types we get (there&#39;s been some =
talk about `stack_array` or whatever).<br><br>Let&#39;s break down the use =
cases. That is, why do we want them to be pointers?<br><br>1) Performance.<=
br><br>2) The ability to use such iterators in pointer-based interfaces wit=
hout having to do `&amp;*` on them.<br><br>3) The ability to get pointers b=
ack from pointer-based interfaces and use them easily.<br><br>I&#39;ve alwa=
ys felt that #1 should always be considered a question of the implementatio=
n. I <i>want</i> the ability for debug builds to be able to do range checki=
ng for me. I also want those checks to vanish in release builds.<br><br>But=
 I think we can achieve #2 and #3 without needing to make them explicitly p=
ointers. We simply need two changes:<br><br>A) Allow these iterators of the=
se types to be <i>implicitly convertible</i> to pointers. That solves #2 ne=
atly.<br><br>B) Allow users to convert a pointer to some element into an it=
erator. That solves #3 neatly.<br><br>B should be a (possibly non-member) f=
unction of the <i>container</i>. That is, you shouldn&#39;t be able to impl=
icitly construct an iterator from a pointer. The container ought to verify =
that the pointer is actually within the range before doing so. And as a non=
-member function, it can be specialized/ADL&#39;d for different types.<br><=
br>Are these good ideas?<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_139_193781386.1446177120188--
------=_Part_138_680252009.1446177120188--

.

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

>
>  Is there any particular scenario which raw pointers would be better?


Non-pointer iterators make debugging significantly slower. In Visual
Studio, even if you have all checks turned off, the mere fact that
operator++ isn't inlined can hurt a lot. People often say that debug
performance shouldn't matter, but for many it does matter.

In Dinkumware's algorithm implementations, among the first things that they
do is _Unchecked() their iterators. They then use sfinae to specialize
certain algorithms for pointers. For example, std::fill can be optimized to
memset in some cases but only if you know the iterator to be a pointer.
Since users can't convert container iterators into pointers they are unable
to implement the same optimizations for their own algorithms. Clearly there
is value in stripping the checks or else they wouldn't be doing it.

In particular, I have found it difficult to confidently compare algorithms
that I write against those in the standard library. When you see the
standard library's *first* priority in implementing an algorithm is
stripping checked iterators and when you have no way to do the same, it
significantly reduces confidence that you are making a fair measurement.

Consider another angle:
  void foo(vector<int>::iterator){}
  void foo(array<int>::iterator){}

On some platforms this is fine and on others it violates ODR. As far as I'm
concerned that is not acceptable. When you have entire classes of important
objects that are implementation defined, the validity of your code becomes
implementation defined. I don't like it much when simple code like this has
implementation defined behavior.

Personally, I feel like an implementation that wants checked iterator types
should be able to provide that -- *it would just not be standard C++
anymore when you do so*. I make the claim that this is perfectly acceptable
because you typically do not want to ship a product with iterator debugging
turned on. So why do we care if some debugging feature is technically ISO
conformant?

I do realize that would be significant and likely unpopular change to make
and don't expect it to happen. I do want these iterators to be pointers
always, but I'm also happy to accept conversion support rather than
maintain status quo.

On Thu, Oct 29, 2015 at 12:51 PM, Joel FALCOU <joel.falcou@gmail.com> wrote:

> As a side use case, I wish I could have our simd::allocator returns
> aligned_ptr (pointer like class that asserts on alignment constraints beign
> violated) and have vector<T,simd::allocator<T>>::pointer be such
> aligned_ptr.
>
> I'm all in favor of such relaxation if it's not relaxed already
>
> On 29/10/2015 18:45, Nevin Liber wrote:
>
>> On 29 October 2015 at 12:27, Nicol Bolas <jmckesson@gmail.com
>> <mailto:jmckesson@gmail.com>> wrote:
>>
>>     That's the question: should the standard explicitly /require/ that
>>     `basic_string`, `vector`, and `array` iterators are pointers?
>>
>>
>> No.
>>
>> Oh, and don't forget valarray.
>>
>> The contiguous iterator trait proposal has a way to convert from a
>> contiguous iterator to a pointer that LEWG likes.  Unfortunately, Real
>> Life(TM) has gotten in the way of me doing the next revision of it, and
>> coming up with the standardese for it isn't easy...
>> --
>>   Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com
>> <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
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto: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/.

--001a114091dae936b405234b17c2
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"><span style=3D"font-size:12.8px">=C2=A0Is=
 there any particular scenario which raw pointers would be better?</span></=
blockquote><div>=C2=A0</div>Non-pointer iterators make debugging significan=
tly slower. In Visual Studio, even if you have all checks turned off, the m=
ere fact that operator++ isn&#39;t inlined can hurt a lot. People often say=
 that debug performance shouldn&#39;t matter, but for many it does matter.<=
div><br></div><div>In Dinkumware&#39;s algorithm implementations, among the=
 first things that they do is _Unchecked() their iterators. They then use s=
finae to specialize certain algorithms for pointers. For example, std::fill=
 can be optimized to memset in some cases but only if you know the iterator=
 to be a pointer. Since users can&#39;t convert container iterators into po=
inters they are unable to implement the same optimizations for their own al=
gorithms. Clearly there is value in stripping the checks or else they would=
n&#39;t be doing it.</div><div><br></div><div>In particular, I have found i=
t difficult to confidently compare algorithms that I write against those in=
 the standard library. When you see the standard library&#39;s *first* prio=
rity in implementing an algorithm is stripping checked iterators and when y=
ou have no way to do the same, it significantly reduces confidence that you=
 are making a fair measurement.</div><div><br></div><div>Consider another a=
ngle:</div><div>=C2=A0 void foo(vector&lt;int&gt;::iterator){}</div><div>=
=C2=A0 void foo(array&lt;int&gt;::iterator){}</div><div><br></div><div>On s=
ome platforms this is fine and on others it violates ODR. As far as I&#39;m=
 concerned that is not acceptable. When you have entire classes of importan=
t objects that are implementation defined, the validity of your code become=
s implementation defined. I don&#39;t like it much when simple code like th=
is has implementation defined behavior.</div><div><br></div><div>Personally=
, I feel like an implementation that wants checked iterator types should be=
 able to provide that -- <i>it would just not be standard C++ anymore when =
you do so</i>. I make the claim that this is perfectly acceptable because y=
ou typically do not want to ship a product with iterator debugging turned o=
n. So why do we care if some debugging feature is technically ISO conforman=
t?</div><div><br></div><div>I do realize that would be significant and like=
ly unpopular change to make and don&#39;t expect it to happen. I do want th=
ese iterators to be pointers always, but I&#39;m also happy to accept conve=
rsion support rather than maintain status quo.</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Thu, Oct 29, 2015 at 12:51 PM, =
Joel FALCOU <span dir=3D"ltr">&lt;<a href=3D"mailto:joel.falcou@gmail.com" =
target=3D"_blank">joel.falcou@gmail.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">As a side use case, I wish I could have our simd::allo=
cator returns aligned_ptr (pointer like class that asserts on alignment con=
straints beign violated) and have vector&lt;T,simd::allocator&lt;T&gt;&gt;:=
:pointer be such aligned_ptr.<br>
<br>
I&#39;m all in favor of such relaxation if it&#39;s not relaxed already<spa=
n class=3D""><br>
<br>
On 29/10/2015 18:45, Nevin Liber wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
On 29 October 2015 at 12:27, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gm=
ail.com" target=3D"_blank">jmckesson@gmail.com</a><br></span>
&lt;mailto:<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckess=
on@gmail.com</a>&gt;&gt; wrote:<br>
<br>
=C2=A0 =C2=A0 That&#39;s the question: should the standard explicitly /requ=
ire/ that<span class=3D""><br>
=C2=A0 =C2=A0 `basic_string`, `vector`, and `array` iterators are pointers?=
<br>
<br>
<br>
No.<br>
<br>
Oh, and don&#39;t forget valarray.<br>
<br>
The contiguous iterator trait proposal has a way to convert from a<br>
contiguous iterator to a pointer that LEWG likes.=C2=A0 Unfortunately, Real=
<br>
Life(TM) has gotten in the way of me doing the next revision of it, and<br>
coming up with the standardese for it isn&#39;t easy...<br>
--<br>
=C2=A0 Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a><br>
&lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevi=
n@eviloverlord.com</a>&gt;&gt;=C2=A0 <a href=3D"tel:%28847%29%20691-1404" v=
alue=3D"+18476911404" target=3D"_blank">(847) 691-1404</a><br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google<br>
Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send<br>
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" targe=
t=3D"_blank">std-proposals+unsubscribe@isocpp.org</a><br></span>
&lt;mailto:<a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=
=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>&gt;.<span class=3D""><=
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></span>
&lt;mailto:<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">st=
d-proposals@isocpp.org</a>&gt;.<span class=3D""><br>
Visit this group at<br>
<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/gro=
up/std-proposals/</a>.<br>
</span></blockquote><div class=3D"HOEnZb"><div class=3D"h5">
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" 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 />

--001a114091dae936b405234b17c2--

.

------=_Part_698_1360331822.1446213505654
Content-Type: multipart/alternative;
 boundary="----=_Part_699_333955869.1446213505654"

------=_Part_699_333955869.1446213505654
Content-Type: text/plain; charset=UTF-8



On Friday, October 30, 2015 at 12:45:16 AM UTC-4, Brent Friedman wrote:
>
>  Is there any particular scenario which raw pointers would be better?
>
>
> Non-pointer iterators make debugging significantly slower. In Visual
> Studio, even if you have all checks turned off, the mere fact that
> operator++ isn't inlined can hurt a lot. People often say that debug
> performance shouldn't matter, but for many it does matter.
>

If basic inlining is not possible with your particular compilation
settings, I think you've got far worse performance problems to worry about
than whether operator++ gets inlined.

In Dinkumware's algorithm implementations, among the first things that they
> do is _Unchecked() their iterators. They then use sfinae to specialize
> certain algorithms for pointers. For example, std::fill can be optimized to
> memset in some cases but only if you know the iterator to be a pointer.
> Since users can't convert container iterators into pointers they are unable
> to implement the same optimizations for their own algorithms. Clearly there
> is value in stripping the checks or else they wouldn't be doing it.
>
> In particular, I have found it difficult to confidently compare algorithms
> that I write against those in the standard library. When you see the
> standard library's *first* priority in implementing an algorithm is
> stripping checked iterators and when you have no way to do the same, it
> significantly reduces confidence that you are making a fair measurement.
>

.... and?

The standard library implementation shipped with your compiler is allowed
to cheat. It's allowed to use specific knowledge of the implementation of
containers/etc to achieve better performance or whatever. Standard library
implementations are allowed to rely on compiler-specific behavior as well.

The fact that you *can't* beat the standard library implementation is not a
bug; it's a feature.


> Consider another angle:
>   void foo(vector<int>::iterator){}
>   void foo(array<int>::iterator){}
>
> On some platforms this is fine and on others it violates ODR. As far as
> I'm concerned that is not acceptable. When you have entire classes of
> important objects that are implementation defined, the validity of your
> code becomes implementation defined. I don't like it much when simple code
> like this has implementation defined behavior.
>

I'm curious as to what in the C++ standard allows these two clearly
distinct types to potentially be the same. That is, exactly where does the
standard make it clear that this is possible?

Once we finally get opaque typedefs, we can solve that problem easily
enough without any performance loss.

Personally, I feel like an implementation that wants checked iterator types
> should be able to provide that -- *it would just not be standard C++
> anymore when you do so*. I make the claim that this is perfectly
> acceptable because you typically do not want to ship a product with
> iterator debugging turned on. So why do we care if some debugging feature
> is technically ISO conformant?
>

Because you want your ISO C++ conformant code to *not break* just because
you performed a debug build.

If contiguous iterators are required by the standard to be pointers, and an
implementation (debug, release or whatever) doesn't make them pointers,
that's *visible behavior*, not mere performance. You can write code that is
*functionally* dependent on them being pointers, and that code will
instantly break when they're not pointers.

Debugging features should not break your 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_699_333955869.1446213505654
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, October 30, 2015 at 12:45:16 AM UTC-4, =
Brent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><span style=3D"font-size:12.8px">=C2=A0Is there a=
ny particular scenario which raw pointers would be better?</span></blockquo=
te><div>=C2=A0</div>Non-pointer iterators make debugging significantly slow=
er. In Visual Studio, even if you have all checks turned off, the mere fact=
 that operator++ isn&#39;t inlined can hurt a lot. People often say that de=
bug performance shouldn&#39;t matter, but for many it does matter.</div></b=
lockquote><div><br>If basic inlining is not possible with your particular c=
ompilation settings, I think you&#39;ve got far worse performance problems =
to worry about than whether operator++ gets inlined.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>In Din=
kumware&#39;s algorithm implementations, among the first things that they d=
o is _Unchecked() their iterators. They then use sfinae to specialize certa=
in algorithms for pointers. For example, std::fill can be optimized to mems=
et in some cases but only if you know the iterator to be a pointer. Since u=
sers can&#39;t convert container iterators into pointers they are unable to=
 implement the same optimizations for their own algorithms. Clearly there i=
s value in stripping the checks or else they wouldn&#39;t be doing it.</div=
><div><br></div><div>In particular, I have found it difficult to confidentl=
y compare algorithms that I write against those in the standard library. Wh=
en you see the standard library&#39;s *first* priority in implementing an a=
lgorithm is stripping checked iterators and when you have no way to do the =
same, it significantly reduces confidence that you are making a fair measur=
ement.</div></div></blockquote><div><br>... and?<br><br>The standard librar=
y implementation shipped with your compiler is allowed to cheat. It&#39;s a=
llowed to use specific knowledge of the implementation of containers/etc to=
 achieve better performance or whatever. Standard library implementations a=
re allowed to rely on compiler-specific behavior as well.<br><br>The fact t=
hat you <i>can&#39;t</i> beat the standard library implementation is not a =
bug; it&#39;s a feature.<br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div></div><div>Consider another angle:</div><di=
v>=C2=A0 void foo(vector&lt;int&gt;::iterator){}</div><div>=C2=A0 void foo(=
array&lt;int&gt;::iterator){}</div><div><br></div><div>On some platforms th=
is is fine and on others it violates ODR. As far as I&#39;m concerned that =
is not acceptable. When you have entire classes of important objects that a=
re implementation defined, the validity of your code becomes implementation=
 defined. I don&#39;t like it much when simple code like this has implement=
ation defined behavior.</div></div></blockquote><div><br>I&#39;m curious as=
 to what in the C++ standard allows these two clearly distinct types to pot=
entially be the same. That is, exactly where does the standard make it clea=
r that this is possible?<br><br>Once we finally get opaque typedefs, we can=
 solve that problem easily enough without any performance loss.<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div>=
<div>Personally, I feel like an implementation that wants checked iterator =
types should be able to provide that -- <i>it would just not be standard C+=
+ anymore when you do so</i>. I make the claim that this is perfectly accep=
table because you typically do not want to ship a product with iterator deb=
ugging turned on. So why do we care if some debugging feature is technicall=
y ISO conformant?</div></div></blockquote><div><br>Because you want your IS=
O C++ conformant code to <i>not break</i> just because you performed a debu=
g build.<br><br>If contiguous iterators are required by the standard to be =
pointers, and an implementation (debug, release or whatever) doesn&#39;t ma=
ke them pointers, that&#39;s <i>visible behavior</i>, not mere performance.=
 You can write code that is <i>functionally</i> dependent on them being poi=
nters, and that code will instantly break when they&#39;re not pointers.<br=
><br>Debugging features should not break your code.<br></div></div>

<p></p>

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

------=_Part_699_333955869.1446213505654--
------=_Part_698_1360331822.1446213505654--

.

--Apple-Mail=_128D31B5-44C5-48D5-9F3F-C36A9BF57D68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

Container iterators are typedefs, there is no requirement that each
container iterator type be unique - in fact there was a paper on
SCARY iterators desiring exactly the opposite - that containers=E2=80=99
iterator type not depend on their allocator, comparator, or other
policy type that would have no effect on navigating the data structure
itself.

AlisdairM

> On Oct 30, 2015, at 9:58 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> I'm curious as to what in the C++ standard allows these two clearly disti=
nct types to potentially be the same. That is, exactly where does the stand=
ard make it clear that this is possible?

--=20

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

--Apple-Mail=_128D31B5-44C5-48D5-9F3F-C36A9BF57D68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">Container iterator=
s are typedefs, there is no requirement that each<div class=3D"">container =
iterator type be unique - in fact there was a paper on</div><div class=3D""=
>SCARY iterators desiring exactly the opposite - that containers=E2=80=99</=
div><div class=3D"">iterator type not depend on their allocator, comparator=
, or other</div><div class=3D"">policy type that would have no effect on na=
vigating the data structure</div><div class=3D"">itself.</div><div class=3D=
""><br class=3D""></div><div class=3D"">AlisdairM</div><div class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On Oct=
 30, 2015, at 9:58 AM, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.co=
m" class=3D"">jmckesson@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-in=
terchange-newline"><div class=3D""><span style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; word-spacing:=
 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !importa=
nt;" class=3D"">I'm curious as to what in the C++ standard allows these two=
 clearly distinct types to potentially be the same. That is, exactly where =
does the standard make it clear that this is possible?</span></div></blockq=
uote></div><br class=3D""></div></body></html>

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

--Apple-Mail=_128D31B5-44C5-48D5-9F3F-C36A9BF57D68--

.

------=_Part_1149_1136671031.1446215098797
Content-Type: multipart/alternative;
 boundary="----=_Part_1150_1060943377.1446215098797"

------=_Part_1150_1060943377.1446215098797
Content-Type: text/plain; charset=UTF-8

On Friday, October 30, 2015 at 6:58:26 AM UTC-7, Nicol Bolas wrote:
>
>
>
> On Friday, October 30, 2015 at 12:45:16 AM UTC-4, Brent Friedman wrote:
>>
>>  Is there any particular scenario which raw pointers would be better?
>>
>>
>> Non-pointer iterators make debugging significantly slower. In Visual
>> Studio, even if you have all checks turned off, the mere fact that
>> operator++ isn't inlined can hurt a lot. People often say that debug
>> performance shouldn't matter, but for many it does matter.
>>
>
> If basic inlining is not possible with your particular compilation
> settings, I think you've got far worse performance problems to worry about
> than whether operator++ gets inlined.
>

Definitely not true. Remember, in debug builds, we're not necessarily
worried about _maximum_ performance but rather _enough_ performance.
"interactive" vs "pretty slideshow" kinda things. :)

Inlining is important, yes, but when your hot loops are often just
iterating over vectors, the behavior of incrementing and dereferencing your
vector iterator can trounce anything else. The only other C++ feature that
compares in my experience is the use of smart pointers vs raw
pointers/references.

Nevin's proposal here is a reasonable improvement since then we could just
use the as_pointer conversion for said loops (assuming our industry ever
stops reimplementing the STL with guaranteed iterator-as-pointer semantics).


>
>
>> Consider another angle:
>>   void foo(vector<int>::iterator){}
>>   void foo(array<int>::iterator){}
>>
>> On some platforms this is fine and on others it violates ODR. As far as
>> I'm concerned that is not acceptable. When you have entire classes of
>> important objects that are implementation defined, the validity of your
>> code becomes implementation defined. I don't like it much when simple code
>> like this has implementation defined behavior.
>>
>
> I'm curious as to what in the C++ standard allows these two clearly
> distinct types to potentially be the same. That is, exactly where does the
> standard make it clear that this is possible?
>

I'd invert that question: what in the standard _doesn't_ allow two "clearly
distinct" member types to be aliases of the same type?

The standard containers requirements only say:

  X::iterator iterator type whose value type is T any iterator category
that meets the forward iterator requirements. convertible to
X::const_iterator.

The vector-specific requirements don't add anything about type distinctness
that I can find.


--

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

On Friday, October 30, 2015 at 6:58:26 AM UTC-7, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Friday, Oc=
tober 30, 2015 at 12:45:16 AM UTC-4, Brent Friedman wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex"><span style=3D"fon=
t-size:12.8px">=C2=A0Is there any particular scenario which raw pointers wo=
uld be better?</span></blockquote><div>=C2=A0</div>Non-pointer iterators ma=
ke debugging significantly slower. In Visual Studio, even if you have all c=
hecks turned off, the mere fact that operator++ isn&#39;t inlined can hurt =
a lot. People often say that debug performance shouldn&#39;t matter, but fo=
r many it does matter.</div></blockquote><div><br>If basic inlining is not =
possible with your particular compilation settings, I think you&#39;ve got =
far worse performance problems to worry about than whether operator++ gets =
inlined.<br></div></div></blockquote><div><br></div><div>Definitely not tru=
e. Remember, in debug builds, we&#39;re not necessarily worried about _maxi=
mum_ performance but rather _enough_ performance. &quot;interactive&quot; v=
s &quot;pretty slideshow&quot; kinda things. :)</div><div><br></div><div>In=
lining is important, yes, but when your hot loops are often just iterating =
over vectors, the behavior of incrementing and dereferencing your vector it=
erator can trounce anything else. The only other C++ feature that compares =
in my experience is the use of smart pointers vs raw pointers/references.</=
div><div><br></div><div>Nevin&#39;s proposal here is a reasonable improveme=
nt since then we could just use the as_pointer conversion for said loops (a=
ssuming our industry ever stops reimplementing the STL with guaranteed iter=
ator-as-pointer semantics).</div><div>=C2=A0<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Consider another an=
gle:</div><div>=C2=A0 void foo(vector&lt;int&gt;::iterator){}</div><div>=C2=
=A0 void foo(array&lt;int&gt;::iterator){}</div><div><br></div><div>On some=
 platforms this is fine and on others it violates ODR. As far as I&#39;m co=
ncerned that is not acceptable. When you have entire classes of important o=
bjects that are implementation defined, the validity of your code becomes i=
mplementation defined. I don&#39;t like it much when simple code like this =
has implementation defined behavior.</div></div></blockquote><div><br>I&#39=
;m curious as to what in the C++ standard allows these two clearly distinct=
 types to potentially be the same. That is, exactly where does the standard=
 make it clear that this is possible?<br></div></div></blockquote><div><br>=
</div><div>I&#39;d invert that question: what in the standard _doesn&#39;t_=
 allow two &quot;clearly distinct&quot; member types to be aliases of the s=
ame type?</div><div><br></div><div>The standard containers requirements onl=
y say:</div><div><br></div><div>=C2=A0 X::iterator iterator type
whose value
type is T
any iterator category
that meets the
forward iterator
requirements.
convertible to
X::const_iterator.<br></div><div><br></div><div>The vector-specific require=
ments don&#39;t add anything about type distinctness that I can find.</div>=
<div>=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_1150_1060943377.1446215098797--
------=_Part_1149_1136671031.1446215098797--

.

On Oct 30, 2015, at 12:45 AM, Brent Friedman <fourthgeek@gmail.com> wrote:
>=20
> Non-pointer iterators make debugging significantly slower. In Visual Stud=
io, even if you have all checks turned off, the mere fact that operator++ i=
sn't inlined can hurt a lot. People often say that debug performance should=
n't matter, but for many it does matter.

Another approach your vendor could take is to force inlining on for iterato=
r::operator++ even in debug mode.  This is what libc++ does.

Howard

--=20

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

.

On Fri, Oct 30, 2015 at 8:36 AM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
> On Oct 30, 2015, at 12:45 AM, Brent Friedman <fourthgeek@gmail.com> wrote=
:
>>
>> Non-pointer iterators make debugging significantly slower. In Visual Stu=
dio, even if you have all checks turned off, the mere fact that operator++ =
isn't inlined can hurt a lot. People often say that debug performance shoul=
dn't matter, but for many it does matter.
>
> Another approach your vendor could take is to force inlining on for itera=
tor::operator++ even in debug mode.  This is what libc++ does.

My two quick thoughts on that specific tweak:

1) Implementation-specific fixes are worthless because modern
multi-platform apps have to target 10+ platforms with implementations
from 5+ vendors. And so long as any single one of those doesn't have
that QoI tweak, the standard library has unpredictable performance
consequences and so we write our own that we know will behave exactly
as we told it to everywhere without question. Such as using a pointer.

2) Why would anyone want to build up that much scaffolding (custom
iterator types, special compiler optimization control, manual tweaking
and optimization, etc.) just to get a slightly-slower-to-compile and
much-harder-to-maintain version of a raw pointer? Just use a pointer.

>
> Howard
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Go=
ogle Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.=
org/d/topic/std-proposals/QR8OMgAjUi0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+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-propo=
sals/.



--=20
Sean Middleditch
http://seanmiddleditch.com

--=20

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

.

On Oct 30, 2015, at 6:27 PM, Sean Middleditch <sean@middleditch.us> wrote:
>=20
> 2) Why would anyone want to build up that much scaffolding (custom
> iterator types, special compiler optimization control, manual tweaking
> and optimization, etc.) just to get a slightly-slower-to-compile and
> much-harder-to-maintain version of a raw pointer? Just use a pointer.

So that you get consistent ADL behavior when you switch containers:

template <class C>
void
test(C& c)
{
    sort(c.begin(), c.end());  // works the same whether c is a std::vector=
 or std::deque
}

But that=E2=80=99s just another QoI issue std::lib vendors deal with.

Howard

--=20

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

.

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

On 30 October 2015 at 17:27, Sean Middleditch <sean@middleditch.us> wrote:

> 1) Implementation-specific fixes are worthless because modern
> multi-platform apps have to target 10+ platforms with implementations
> from 5+ vendors. And so long as any single one of those doesn't have
> that QoI tweak, the standard library has unpredictable performance
> consequences and so we write our own that we know will behave exactly
> as we told it to everywhere without question.


That is pretty much what QoI means, isn't it?  Why aren't your vendors
addressing this issue?


> 2) Why would anyone want to build up that much scaffolding (custom
> iterator types, special compiler optimization control, manual tweaking
> and optimization, etc.) just to get a slightly-slower-to-compile and
> much-harder-to-maintain version of a raw pointer?


Some of us like to have bugs detected at compile time, and the type system
is really good for that.  An iterator into a vector<char> shouldn't
normally work into a string just because they have the same underlying
representation for the data they hold.  Now, there are some operations
where you want to remove that distinction, so you should be able to convert
it to a pointer, but it shouldn't be the default.

I do think that SCARY iterators might be a step too far in the wrong
direction.  While you should be able to convert a container-specific
iterator into a more generic SCARY iterator, but it shouldn't be the
default.  Note:  I'm not sure you can actually do this in practice w/o type
erasure, which would very likely slow down iteration enough to not be worth
it, but I haven't really thought it through.
--
 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/.

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

<div dir=3D"ltr">On 30 October 2015 at 17:27, Sean Middleditch <span dir=3D=
"ltr">&lt;<a href=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@mid=
dleditch.us</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">1) Implementation-specific =
fixes are worthless because modern<br>
multi-platform apps have to target 10+ platforms with implementations<br>
from 5+ vendors. And so long as any single one of those doesn&#39;t have<br=
>
that QoI tweak, the standard library has unpredictable performance<br>
consequences and so we write our own that we know will behave exactly<br>
as we told it to everywhere without question.</blockquote><div><br></div><d=
iv>That is pretty much what QoI means, isn&#39;t it?=C2=A0 Why aren&#39;t y=
our vendors addressing this issue?</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
2) Why would anyone want to build up that much scaffolding (custom<br>
iterator types, special compiler optimization control, manual tweaking<br>
and optimization, etc.) just to get a slightly-slower-to-compile and<br>
much-harder-to-maintain version of a raw pointer?</blockquote><div><br></di=
v><div>Some of us like to have bugs detected at compile time, and the type =
system is really good for that.=C2=A0 An iterator into a vector&lt;char&gt;=
 shouldn&#39;t normally work into a string just because they have the same =
underlying representation for the data they hold.=C2=A0 Now, there are some=
 operations where you want to remove that distinction, so you should be abl=
e to convert it to a pointer, but it shouldn&#39;t be the default.</div><di=
v><br></div><div>I do think that SCARY iterators might be a step too far in=
 the wrong direction.=C2=A0 While you should be able to convert a container=
-specific iterator into a more generic SCARY iterator, but it shouldn&#39;t=
 be the default.=C2=A0 Note: =C2=A0I&#39;m not sure you can actually do thi=
s in practice w/o type erasure, which would very likely slow down iteration=
 enough to not be worth it, but I haven&#39;t really thought it through.</d=
iv></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; =
Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"=
_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

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

--001a11c0130029299d05235a3c2b--

.

------=_Part_737_1816805837.1446273337854
Content-Type: multipart/alternative;
 boundary="----=_Part_738_451836357.1446273337854"

------=_Part_738_451836357.1446273337854
Content-Type: text/plain; charset=UTF-8

I have objections to both of your points below, but I don't want to hijack
another of Jason's threads, so I'll drop the issue. Nevin, I'd be happy to
continue the discussion elsewhere if you're interested; otherwise it'll all
come up in future meetings, I'm sure. :)

On Friday, October 30, 2015 at 3:49:08 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 30 October 2015 at 17:27, Sean Middleditch <se...@middleditch.us
> <javascript:>> wrote:
>
>> 1) Implementation-specific fixes are worthless because modern
>>
> That is pretty much what QoI means, isn't it?  Why aren't your vendors
> addressing this issue?
>


>
>
>> 2) Why would anyone want to build up that much scaffolding (custom
>>
> Some of us like to have bugs detected at compile time, and the type system
> is really good for that.  An iterator into a vector<char> shouldn't
> normally work into a string just because they have the same underlying
> representation for the data they hold.
>


> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

--

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

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

<div dir=3D"ltr"><div>I have objections to both of your points below, but I=
 don&#39;t want to hijack another of Jason&#39;s threads, so I&#39;ll drop =
the issue. Nevin, I&#39;d be happy to continue the discussion elsewhere if =
you&#39;re interested; otherwise it&#39;ll all come up in future meetings, =
I&#39;m sure. :)</div><div><br></div>On Friday, October 30, 2015 at 3:49:08=
 PM UTC-7, Nevin &quot;:-)&quot; Liber wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr">On 30 October 2015 at 17:27, Sean Middledit=
ch <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"RkARe1CdEwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">se...@middleditch.us</a>&gt;</span> wrote:<br><div><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">1) Implementation-spe=
cific fixes are worthless because modern<br></blockquote><div>That is prett=
y much what QoI means, isn&#39;t it?=C2=A0 Why aren&#39;t your vendors addr=
essing this issue?</div></div></div></div></blockquote><div>=C2=A0<br></div=
><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"><div class=
=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Why would anyone want to build up that much scaffolding (custom<br></blo=
ckquote><div>Some of us like to have bugs detected at compile time, and the=
 type system is really good for that.=C2=A0 An iterator into a vector&lt;ch=
ar&gt; shouldn&#39;t normally work into a string just because they have the=
 same underlying representation for the data they hold.</div></div></div></=
blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">-- <br><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mail=
to:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"RkARe=
1CdEwAJ" 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><wbr>&gt;=C2=A0 (847) 691-1404</div>
</div>
</blockquote></div>

<p></p>

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

------=_Part_738_451836357.1446273337854--
------=_Part_737_1816805837.1446273337854--

.

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

On 31 October 2015 at 01:35, Sean Middleditch <sean.middleditch@gmail.com>
wrote:

> I have objections to both of your points below, but I don't want to hijack
> another of Jason's threads, so I'll drop the issue. Nevin, I'd be happy to
> continue the discussion elsewhere if you're interested; otherwise it'll all
> come up in future meetings, I'm sure. :)
>

Feel free to start another thread somewhere; just let me know where.
--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 31 October 2015 at 01:35, Se=
an Middleditch <span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middleditch@gma=
il.com" target=3D"_blank">sean.middleditch@gmail.com</a>&gt;</span> wrote:<=
br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I have ob=
jections to both of your points below, but I don&#39;t want to hijack anoth=
er of Jason&#39;s threads, so I&#39;ll drop the issue. Nevin, I&#39;d be ha=
ppy to continue the discussion elsewhere if you&#39;re interested; otherwis=
e it&#39;ll all come up in future meetings, I&#39;m sure. :)</div><div></di=
v></blockquote></div><br>Feel free to start another thread somewhere; just =
let me know where.<br>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &qu=
ot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.co=
m" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</d=
iv>
</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 />

--001a1143f1c0ed50cb0523884ef3--

.

------=_Part_1200_661705698.1446758955155
Content-Type: multipart/alternative;
 boundary="----=_Part_1201_20465641.1446758955157"

------=_Part_1201_20465641.1446758955157
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So one thought that comes to mind. Is that if some iterators were=20
*required* to be just pointers. Then it can easily result in difficult to=
=20
use (and difficult write) APIs. Consider the following example String class=
=20
with a minimal interface to demonstrate:

#include <string>
#include <iterator>

template <class Ch, class Tr =3D std::char_traits<Ch>>
class String {
public:
 typedef const Ch *const_iterator;
 // assume basically the same set of methods as basic_string<Ch, Tr, A>
public:
 // just enough to make it compile, no real functionality here
 const_iterator begin() const { return nullptr; }
 const_iterator end() const { return nullptr; }
};


So we've templated on character type and traits type because we want the=20
same flexibility as std::basic_string. Seams reasonable enough. Here's=20
where the trouble comes in. Now I want to make a function which accepts two=
=20
iterators, and returns an object of this type:

Here's the first attempt:

template <class In>
auto substr(In first, In last) -> String<typename std::iterator_traits<In>:=
:
value_type, std::char_traits<typename std::iterator_traits<In>::value_type>=
>=20
{
 String<typename std::iterator_traits<In>::value_type, std::char_traits<
typename std::iterator_traits<In>::value_type>> s;
 return s;
}

So that's a nightmare! And on top of that we *lost the type of the traits*;=
=20
we had to assume the usage of std::char_traits. Since there is no iterator=
=20
trait that could ever hope to get us the character traits type. Sure, the=
=20
user can specify both the character and trait types at call time, but this=
=20
is getting ugly FAST. It took over 100 characters to specify the String=20
type...but at least it compiles for the basic use case.

Eventually, we give us and try to pass specific iterator types since we=20
want seemless usage for the user:

template <class Ch, class Tr>
String<Ch, Tr> substr(typename String<Ch,Tr>::const_iterator first, typenam=
e=20
String<Ch,Tr>::const_iterator last) {
 String<Ch, Tr> s;
 return s;
}

This was easy to write and seems clear enough. But again we run into=20
issues. When we write "typename String<Ch,Tr>::const_iterator", the=20
compiler thinks "const char *". So when it comes to usage like this (which=
=20
is what we want the user to be able to write)

int main() {
 String<char> str;
 auto sub =3D substr(str.begin(), str.end());
}

we actually get a compiler error!

$ g++ -std=3Dc++11 String.cpp -o String
String.cpp: In function =E2=80=98int main()=E2=80=99:
String.cpp:32:42: error: no matching function for call to =E2=80=98substr(S=
tring
<char>::const_iterator, String<char>::const_iterator)=E2=80=99
  auto sub =3D substr(str.begin(), str.end());
                                          ^
String.cpp:32:42: note: candidate is:
String.cpp:18:16: note: template<class Ch, class Tr> String<Ch, Tr> substr(
typename String<Ch, Tr>::const_iterator, typename String<Ch, Tr>::
const_iterator)
 String<Ch, Tr> substr(typename String<Ch,Tr>::const_iterator first,=20
typename String<Ch,Tr>::const_iterator last) {
                ^
String.cpp:18:16: note:   template argument deduction/substitution failed:
String.cpp:32:42: note:   couldn't deduce template parameter =E2=80=98Ch=E2=
=80=99
  auto sub =3D substr(str.begin(), str.end());


The compiler can't deduce the Ch and Tr types. Because begin() and end()=20
are basically reduced to a const char *. The type information is simply=20
lost.

So in the first case, the user has to specify all template parameters if=20
they want custom traits. In the second example, they basically always have=
=20
to specify all template parameters. If typename String<Ch,=20
Tr>::const_iterator were an actual unique type that depends on the template=
=20
parameters, it "just works" as expected. I experienced this is=20
implementations of the standard library already. So I can attest that it=20
results in a ery frustrating user experience involving shouting "what do=20
you mean you can't convert he result of begin() to the iterator type??!?!?!=
"

This isn't necessarily me trying to say "iterators as pointers is=20
unconditionally bad". Just that there is a real tangable downside in user=
=20
experience if not dealt with carefully.=20

Thoughts?

On Monday, November 2, 2015 at 12:47:13 AM UTC-5, Nevin ":-)" Liber wrote:
>
> On 31 October 2015 at 01:35, Sean Middleditch <sean.mid...@gmail.com=20
> <javascript:>> wrote:
>
>> I have objections to both of your points below, but I don't want to=20
>> hijack another of Jason's threads, so I'll drop the issue. Nevin, I'd be=
=20
>> happy to continue the discussion elsewhere if you're interested; otherwi=
se=20
>> it'll all come up in future meetings, I'm sure. :)
>>
>
> Feel free to start another thread somewhere; just let me know where.
> --=20
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)=
=20
> 691-1404
>

--=20

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

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

<div dir=3D"ltr">So one thought that comes to mind. Is that if some iterato=
rs were *required* to be just pointers. Then it can easily result in diffic=
ult to use=C2=A0(and difficult write)=C2=A0APIs. Consider the following exa=
mple String class with a minimal interface to demonstrate:<div><br></div><d=
iv><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187)=
; word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">#include</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">&lt;string&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">#include</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">&lt;iterator&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">template</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Tr</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">char_traits</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">String</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">public</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">typedef</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Ch</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>const_iterator</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// a=
ssume basically the same set of methods as basic_string&lt;Ch, Tr, A&gt;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">// just enough to make it compil=
e, no real functionality here</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0const_iterator </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">begin</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">nullptr</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0const_iterator </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">nullptr</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span></div></code></div><div><br>So we&#39;ve templated on character type=
 and traits type because we want the same flexibility as std::basic_string.=
 Seams reasonable enough. Here&#39;s where the trouble comes in. Now I want=
 to make a function which accepts two iterators, and returns an object of t=
his type:</div><div><br></div><div>Here&#39;s the first attempt:</div><div>=
<br></div><div><div><div class=3D"prettyprint" style=3D"border: 1px solid r=
gb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 2=
50);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">In</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">au=
to</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> substr<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">In</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> first</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">In</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">last</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">String</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">iterator_traits</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">In</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">value_type</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">char_traits</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">iterator_traits</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">In</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">value_type</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&gt;&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0</span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">String</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">type=
name</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">iterator_traits</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">In</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">value_type</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">char_traits</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i=
terator_traits</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">In=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">value_type</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> s</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> s</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span></div></code></div><div><br></div></div><div>So that=
&#39;s a nightmare! And on top of that we <b>lost the type of the traits</b=
>; we had to assume the usage of std::char_traits. Since there is no iterat=
or trait that could ever hope to get us the character traits type. Sure, th=
e user can specify both the character and trait types at call time, but thi=
s is getting ugly FAST. It took over 100 characters to specify the String t=
ype...but at least it compiles for the basic use case.</div><div><br></div>=
<div>Eventually, we give us and try to pass specific iterator types since w=
e want seemless usage for the user:</div><div><br></div><div><div class=3D"=
prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: brea=
k-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">template</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">clas=
s</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Tr</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #606;" class=3D"styled-by-prettify">Str=
ing</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> substr</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>String</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Tr</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">const_iterator first</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">String</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Ch</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">const_iterator </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">last</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">String</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> s</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> s</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span></div></code></div><div><br></div></div>This was easy to=
 write and seems clear enough. But again we run into issues. When we write =
&quot;typename String&lt;Ch,Tr&gt;::const_iterator&quot;, the compiler thin=
ks &quot;const char *&quot;. So when it comes to usage like this (which is =
what we want the user to be able to write)<div><span class=3D"styled-by-pre=
ttify" style=3D"font-family: monospace; color: rgb(0, 0, 0); background-col=
or: rgb(250, 250, 250);"><br></span></div><div><span class=3D"styled-by-pre=
ttify"><font color=3D"#000000" face=3D"monospace"><div class=3D"prettyprint=
" style=3D"border: 1px solid rgb(187, 187, 187); border-image-source: initi=
al; border-image-slice: initial; border-image-width: initial; border-image-=
outset: initial; border-image-repeat: initial; word-wrap: break-word; backg=
round-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">String</span><span style=3D"color: #0=
80;" class=3D"styled-by-prettify">&lt;char&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> str</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">sub</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> substr</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">str</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">begin</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> str</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">end</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div><=
/code></div><div style=3D"background-color: rgb(250, 250, 250);"><br></div>=
</font>we actually get a compiler error!</span></div><div><span class=3D"st=
yled-by-prettify"><br></span></div><div><span class=3D"styled-by-prettify">=
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">$ g</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">++</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">-</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">c</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">++</span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">11</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">String</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">cpp </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">-</span><span style=3D"color: #000;" class=3D"styled-by-prettify">o </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">String</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">String</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">cpp</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">In</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">fu=
nction</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=E2=80=98</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">()=E2=80=99:</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">String</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">cpp</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">:</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">32</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">:</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>42</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> error</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">no</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> matching </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">function</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">for</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> call to </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=E2=80=98</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">substr</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Str=
ing</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;cha=
r&gt;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">const_iterato=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">String</span><span style=3D=
"color: #080;" class=3D"styled-by-prettify">&lt;char&gt;</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">const_iterator</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)=E2=80=99</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">sub</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> substr</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">str<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> str</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">());</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">^</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #606;" class=3D"styled-by-prettify">String<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">cpp</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">32</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">:</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">42</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> note</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> candid=
ate </span><span style=3D"color: #008;" class=3D"styled-by-prettify">is</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">String</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">cpp</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">:</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">18</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">:</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>16</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> note</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Tr</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">String</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> substr</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">String</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">const_iterator</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">String</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">const_iterator=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">String</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Tr</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> substr</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">String</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">const_iterator first</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>String</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Tr</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">const_iterator </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">last</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">^</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">String</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">cpp</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">18</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">:</span><span style=3D"color: #066;" class=3D"styled-by-prettify">16=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> note</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> =C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> argument deduction</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">/</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">substitution failed</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">String</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">cpp</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">:</span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">32</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">42</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> note</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> =C2=A0 couldn</span><span style=3D"color: #0=
80;" class=3D"styled-by-prettify">&#39;t deduce template parameter =E2=80=
=98Ch=E2=80=99<br>=C2=A0 auto sub =3D substr(str.begin(), str.end());<br><b=
r></span></div></code></div><div><br></div><div>The compiler can&#39;t dedu=
ce the Ch and Tr types. Because begin() and end() are basically reduced to =
a const char *. The type information is simply lost.</div><div><br>So in th=
e first case, the user has to specify all template parameters if they want =
custom traits. In the second example, they basically always have to specify=
 all template parameters. If typename String&lt;Ch, Tr&gt;::const_iterator =
were an actual unique type that depends on the template parameters, it &quo=
t;just works&quot; as expected. I experienced this is implementations of th=
e standard library already. So I can attest that it results in a ery frustr=
ating user experience involving shouting &quot;what do you mean you can&#39=
;t convert he result of begin() to the iterator type??!?!?!&quot;</div><div=
><br></div><div>This isn&#39;t necessarily me trying to say &quot;iterators=
 as pointers is unconditionally bad&quot;. Just that there is a real tangab=
le downside in user experience if not dealt with carefully.=C2=A0</div><div=
><br></div><div>Thoughts?</div></span></div><div><br></div>On Monday, Novem=
ber 2, 2015 at 12:47:13 AM UTC-5, Nevin &quot;:-)&quot; Liber wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>On 31 October 2=
015 at 01:35, Sean Middleditch <span dir=3D"ltr">&lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"tUvj_UlRFAAJ" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">sean.mid...@gmail.com</a>&g=
t;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div>I have objections to both of your points below, but I don&#39;t wan=
t to hijack another of Jason&#39;s threads, so I&#39;ll drop the issue. Nev=
in, I&#39;d be happy to continue the discussion elsewhere if you&#39;re int=
erested; otherwise it&#39;ll all come up in future meetings, I&#39;m sure. =
:)</div><div></div></blockquote></div><br>Feel free to start another thread=
 somewhere; just let me know where.<br>-- <br><div>=C2=A0Nevin &quot;:-)&qu=
ot; Liber=C2=A0 &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"tUvj_UlRFAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">ne...@eviloverlord.com</a><wbr>&gt;=C2=A0 (847) 691-=
1404</div>
</div></div>
</blockquote></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 />

------=_Part_1201_20465641.1446758955157--
------=_Part_1200_661705698.1446758955155--

.

On Thursday 05 November 2015 13:29:15 Evan Teran wrote:
> Here's the first attempt:
>=20
> template <class In>
> auto substr(In first, In last) -> String<typename std::iterator_traits<In=
>::
> value_type, std::char_traits<typename
> std::iterator_traits<In>::value_type>> {
>  String<typename std::iterator_traits<In>::value_type, std::char_traits<
> typename std::iterator_traits<In>::value_type>> s;
>  return s;
> }
>=20
> So that's a nightmare!

Only because you didn't use C++14's return type deduction.

> And on top of that we *lost the type of the traits*;

Which you'd have lost anyway, given SCARY iterators.

> we had to assume the usage of std::char_traits. Since there is no iterato=
r
> trait that could ever hope to get us the character traits type. Sure, the
> user can specify both the character and trait types at call time, but thi=
s
> is getting ugly FAST. It took over 100 characters to specify the String
> type...but at least it compiles for the basic use case.

You don't have a choice as long as pointer iterators are permitted. The=20
function above does not support the argument you wrote about. The function =
and=20
your comments are asking for prohibiting pointer and SCARY iterators=20
altogether.

> Eventually, we give us and try to pass specific iterator types since we
> want seemless usage for the user:
>=20
> template <class Ch, class Tr>
> String<Ch, Tr> substr(typename String<Ch,Tr>::const_iterator first, typen=
ame
> String<Ch,Tr>::const_iterator last) {
>  String<Ch, Tr> s;
>  return s;
> }
>=20
> This was easy to write and seems clear enough. But again we run into
> issues. When we write "typename String<Ch,Tr>::const_iterator", the
> compiler thinks "const char *".=20

Why? Your const_iterator is const Ch*, not const char *.

> So when it comes to usage like this (which
> is what we want the user to be able to write)
>=20
> int main() {
>  String<char> str;
>  auto sub =3D substr(str.begin(), str.end());
> }
>=20
> we actually get a compiler error!
>=20
> $ g++ -std=3Dc++11 String.cpp -o String
> String.cpp: In function =E2=80=98int main()=E2=80=99:
> String.cpp:32:42: error: no matching function for call to =E2=80=98substr=
(String
> <char>::const_iterator, String<char>::const_iterator)=E2=80=99
>   auto sub =3D substr(str.begin(), str.end());
>                                           ^
> String.cpp:32:42: note: candidate is:
> String.cpp:18:16: note: template<class Ch, class Tr> String<Ch, Tr> subst=
r(
> typename String<Ch, Tr>::const_iterator, typename String<Ch, Tr>::
> const_iterator)
>  String<Ch, Tr> substr(typename String<Ch,Tr>::const_iterator first,
> typename String<Ch,Tr>::const_iterator last) {
>                 ^
> String.cpp:18:16: note:   template argument deduction/substitution failed=
:
> String.cpp:32:42: note:   couldn't deduce template parameter =E2=80=98Ch=
=E2=80=99
>   auto sub =3D substr(str.begin(), str.end());
>=20
>=20
> The compiler can't deduce the Ch and Tr types. Because begin() and end()
> are basically reduced to a const char *. The type information is simply
> lost.

Right. Again, this is an argument for forbidding pointer iterators complete=
ly.

> This isn't necessarily me trying to say "iterators as pointers is
> unconditionally bad". Just that there is a real tangable downside in user
> experience if not dealt with carefully.

Actually, it is.

Unless you want to write your algorithms in such a way that they will not=
=20
support std::basic_string and std::vector. If you're not aiming to support=
=20
those, why would you be writing your API to mimic them?

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

--=20

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

.

------=_Part_1218_636645749.1446761584682
Content-Type: multipart/alternative;
 boundary="----=_Part_1219_603485844.1446761584682"

------=_Part_1219_603485844.1446761584682
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


>
>
> > So that's a nightmare!=20
>
> Only because you didn't use C++14's return type deduction.=20


You're right. I was still basing my example on c++11 syntax. But the=20
function body would still have include the complex type declaration.=20
Definitely simpler, but still more pain that preferable.
=20

> =20
>
> And on top of that we *lost the type of the traits*;=20
>
> Which you'd have lost anyway, given SCARY iterators.=20
>

Agreed, SCARY iterators result in similar difficulties.

> we had to assume the usage of std::char_traits. Since there is no=20
> iterator=20
> > trait that could ever hope to get us the character traits type. Sure,=
=20
> the=20
> > user can specify both the character and trait types at call time, but=
=20
> this=20
> > is getting ugly FAST. It took over 100 characters to specify the String=
=20
> > type...but at least it compiles for the basic use case.=20
>
> You don't have a choice as long as pointer iterators are permitted. The=
=20
> function above does not support the argument you wrote about. The functio=
n=20
> and=20
> your comments are asking for prohibiting pointer and SCARY iterators=20
> altogether.=20


To, be clear. I am not trying to suggest that pointer/SCARY iterators be=20
prohibited. But am trying to argue that they shouldn't be mandated either.=
=20
Since there is a downside (at least from my perspective). Since there are=
=20
pros and cons to be discussed, it's probably best left as is, as a QOI=20
concern.
=20

> =20
>
> Eventually, we give us and try to pass specific iterator types since we=
=20
> > want seemless usage for the user:=20
> >=20
> > template <class Ch, class Tr>=20
> > String<Ch, Tr> substr(typename String<Ch,Tr>::const_iterator first,=20
> typename=20
> > String<Ch,Tr>::const_iterator last) {=20
> >  String<Ch, Tr> s;=20
> >  return s;=20
> > }=20
> >=20
> > This was easy to write and seems clear enough. But again we run into=20
> > issues. When we write "typename String<Ch,Tr>::const_iterator", the=20
> > compiler thinks "const char *".=20
>
> Why? Your const_iterator is const Ch*, not const char *.=20


Sure, I did mean  "const Ch *" here.=20
=20

> =20
>
> So when it comes to usage like this (which=20
> > is what we want the user to be able to write)=20
> >=20
> > int main() {=20
> >  String<char> str;=20
> >  auto sub =3D substr(str.begin(), str.end());=20
> > }=20
> >=20
> > we actually get a compiler error!=20
> >=20
> > $ g++ -std=3Dc++11 String.cpp -o String=20
> > String.cpp: In function =E2=80=98int main()=E2=80=99:=20
> > String.cpp:32:42: error: no matching function for call to =E2=80=98subs=
tr(String=20
> > <char>::const_iterator, String<char>::const_iterator)=E2=80=99=20
> >   auto sub =3D substr(str.begin(), str.end());=20
> >                                           ^=20
> > String.cpp:32:42: note: candidate is:=20
> > String.cpp:18:16: note: template<class Ch, class Tr> String<Ch, Tr>=20
> substr(=20
> > typename String<Ch, Tr>::const_iterator, typename String<Ch, Tr>::=20
> > const_iterator)=20
> >  String<Ch, Tr> substr(typename String<Ch,Tr>::const_iterator first,=20
> > typename String<Ch,Tr>::const_iterator last) {=20
> >                 ^=20
> > String.cpp:18:16: note:   template argument deduction/substitution=20
> failed:=20
> > String.cpp:32:42: note:   couldn't deduce template parameter =E2=80=98C=
h=E2=80=99=20
> >   auto sub =3D substr(str.begin(), str.end());=20
> >=20
> >=20
> > The compiler can't deduce the Ch and Tr types. Because begin() and end(=
)=20
> > are basically reduced to a const char *. The type information is simply=
=20
> > lost.=20
>
> Right. Again, this is an argument for forbidding pointer iterators=20
> completely.=20
>

Or perhaps an argument for opaque typedefs... I think they would the second=
=20
example at least as well as the first template based one.=20

>
> > This isn't necessarily me trying to say "iterators as pointers is=20
> > unconditionally bad". Just that there is a real tangable downside in=20
> user=20
> > experience if not dealt with carefully.=20
>
> Actually, it is.=20
>
> Unless you want to write your algorithms in such a way that they will not=
=20
> support std::basic_string and std::vector. If you're not aiming to suppor=
t=20
> those, why would you be writing your API to mimic them?=20


I can see why it may appear that way. Which is why I tried to that wasn't=
=20
my intention. To be clear, the intent of my argument is not to forbid=20
pointer/SCARY iterators. But instead to continue to allow non-pointer/SCARY=
=20
iterators and let the library writers choose what they feel is best. I do=
=20
agree that in order to avoid the issues in the example I gave entirely,=20
they would in fact have to be forbidden (or some other mechanism would need=
=20
to be added to the language to work around the problem altogether).
=20

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

--=20

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>&gt; So t=
hat&#39;s a nightmare!
<br>
<br>Only because you didn&#39;t use C++14&#39;s return type deduction. </bl=
ockquote><div><br></div><div>You&#39;re right. I was still basing my exampl=
e on c++11 syntax. But the function body would still have include the compl=
ex type declaration. Definitely simpler, but still more pain that preferabl=
e.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=C2=
=A0<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; And o=
n top of that we *lost the type of the traits*;
<br>
<br>Which you&#39;d have lost anyway, given SCARY iterators.
<br></blockquote><div><br></div><div>Agreed, SCARY iterators result in simi=
lar difficulties.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">&gt; we had to assume the usage of std::char_traits. Since there is=
 no iterator
<br>&gt; trait that could ever hope to get us the character traits type. Su=
re, the
<br>&gt; user can specify both the character and trait types at call time, =
but this
<br>&gt; is getting ugly FAST. It took over 100 characters to specify the S=
tring
<br>&gt; type...but at least it compiles for the basic use case.
<br>
<br>You don&#39;t have a choice as long as pointer iterators are permitted.=
 The=20
<br>function above does not support the argument you wrote about. The funct=
ion and=20
<br>your comments are asking for prohibiting pointer and SCARY iterators=20
<br>altogether. </blockquote><div><br></div><div>To, be clear. I am not try=
ing to suggest that pointer/SCARY iterators be prohibited. But am trying to=
 argue that they shouldn&#39;t be mandated either. Since there is a downsid=
e (at least from my perspective). Since there are pros and cons to be discu=
ssed, it&#39;s probably best left as is, as a QOI concern.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">=C2=A0<br></blockquote><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">&gt; Eventually, we give us and=
 try to pass specific iterator types since we
<br>&gt; want seemless usage for the user:
<br>&gt;=20
<br>&gt; template &lt;class Ch, class Tr&gt;
<br>&gt; String&lt;Ch, Tr&gt; substr(typename String&lt;Ch,Tr&gt;::const_it=
erator first, typename
<br>&gt; String&lt;Ch,Tr&gt;::const_iterator last) {
<br>&gt; =C2=A0String&lt;Ch, Tr&gt; s;
<br>&gt; =C2=A0return s;
<br>&gt; }
<br>&gt;=20
<br>&gt; This was easy to write and seems clear enough. But again we run in=
to
<br>&gt; issues. When we write &quot;typename String&lt;Ch,Tr&gt;::const_it=
erator&quot;<wbr>, the
<br>&gt; compiler thinks &quot;const char *&quot;.=20
<br>
<br>Why? Your const_iterator is const Ch*, not const char *. </blockquote><=
div><br></div><div>Sure, I did mean =C2=A0&quot;const Ch *&quot; here.=C2=
=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=C2=
=A0<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; So wh=
en it comes to usage like this (which
<br>&gt; is what we want the user to be able to write)
<br>&gt;=20
<br>&gt; int main() {
<br>&gt; =C2=A0String&lt;char&gt; str;
<br>&gt; =C2=A0auto sub =3D substr(str.begin(), str.end());
<br>&gt; }
<br>&gt;=20
<br>&gt; we actually get a compiler error!
<br>&gt;=20
<br>&gt; $ g++ -std=3Dc++11 String.cpp -o String
<br>&gt; String.cpp: In function =E2=80=98int main()=E2=80=99:
<br>&gt; String.cpp:32:42: error: no matching function for call to =E2=80=
=98substr(String
<br>&gt; &lt;char&gt;::const_iterator, String&lt;char&gt;::const_iterator)=
=E2=80=99
<br>&gt; =C2=A0 auto sub =3D substr(str.begin(), str.end());
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 ^
<br>&gt; String.cpp:32:42: note: candidate is:
<br>&gt; String.cpp:18:16: note: template&lt;class Ch, class Tr&gt; String&=
lt;Ch, Tr&gt; substr(
<br>&gt; typename String&lt;Ch, Tr&gt;::const_iterator, typename String&lt;=
Ch, Tr&gt;::
<br>&gt; const_iterator)
<br>&gt; =C2=A0String&lt;Ch, Tr&gt; substr(typename String&lt;Ch,Tr&gt;::co=
nst_iterator first,
<br>&gt; typename String&lt;Ch,Tr&gt;::const_iterator last) {
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^
<br>&gt; String.cpp:18:16: note: =C2=A0 template argument deduction/substit=
ution failed:
<br>&gt; String.cpp:32:42: note: =C2=A0 couldn&#39;t deduce template parame=
ter =E2=80=98Ch=E2=80=99
<br>&gt; =C2=A0 auto sub =3D substr(str.begin(), str.end());
<br>&gt;=20
<br>&gt;=20
<br>&gt; The compiler can&#39;t deduce the Ch and Tr types. Because begin()=
 and end()
<br>&gt; are basically reduced to a const char *. The type information is s=
imply
<br>&gt; lost.
<br>
<br>Right. Again, this is an argument for forbidding pointer iterators comp=
letely.
<br></blockquote><div><br></div><div>Or perhaps an argument for opaque type=
defs... I think they would the second example at least as well as the first=
 template based one.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">
<br>&gt; This isn&#39;t necessarily me trying to say &quot;iterators as poi=
nters is
<br>&gt; unconditionally bad&quot;. Just that there is a real tangable down=
side in user
<br>&gt; experience if not dealt with carefully.
<br>
<br>Actually, it is.
<br>
<br>Unless you want to write your algorithms in such a way that they will n=
ot=20
<br>support std::basic_string and std::vector. If you&#39;re not aiming to =
support=20
<br>those, why would you be writing your API to mimic them? </blockquote><d=
iv><br></div><div>I can see why it may appear that way. Which is why I trie=
d to that wasn&#39;t my intention. To be clear, the intent of my argument i=
s not to forbid pointer/SCARY iterators. But instead to continue to allow n=
on-pointer/SCARY iterators and let the library writers choose what they fee=
l is best. I do agree that in order to avoid the issues in the example I ga=
ve entirely, they would in fact have to be forbidden (or some other mechani=
sm would need to be added to the language to work around the problem altoge=
ther).</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
=C2=A0<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46snt=
z\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;">maciei=
ra.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1Dowztw=
AHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google=
..com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo=
5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
 5358
<br>
<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 />

------=_Part_1219_603485844.1446761584682--
------=_Part_1218_636645749.1446761584682--

.

On Thursday 05 November 2015 14:13:04 Evan Teran wrote:
> > Actually, it is.
> >
> > Unless you want to write your algorithms in such a way that they will not
> > support std::basic_string and std::vector. If you're not aiming to
> > support
> > those, why would you be writing your API to mimic them?
>
> I can see why it may appear that way. Which is why I tried to that wasn't
> my intention. To be clear, the intent of my argument is not to forbid
> pointer/SCARY iterators. But instead to continue to allow non-pointer/SCARY
> iterators and let the library writers choose what they feel is best. I do
> agree that in order to avoid the issues in the example I gave entirely,
> they would in fact have to be forbidden (or some other mechanism would need
> to be added to the language to work around the problem altogether).

In what way is the current proposal going to be a problem for library authors?
It's only about basic_string and vector, not your library.

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

--

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

.

------=_Part_1298_1902974178.1446765257147
Content-Type: multipart/alternative;
 boundary="----=_Part_1299_975967649.1446765257147"

------=_Part_1299_975967649.1446765257147
Content-Type: text/plain; charset=UTF-8


>
> In what way is the current proposal going to be a problem for library
> authors?
> It's only about basic_string and vector, not your library.
>

I don't believe that it is a problem for library authors, and is certainly
not an issue for any library that I'm writing.

My original concern was it potentially resulting in APIs that are difficult
to use for users. Concerns similar to this are not without precedent; for
example http://wg21.cmeerw.net/lwg/issue434, talks about how having the
user supply template parameters make the API hard to use. It was agreed
that adding extra overloads to make it simpler to use was an improvement.

As a real world example, I have run into issues where code using the
current standard library failed to compile with very cryptic errors. All
because that particular implementation chose to use plain pointers as the
std::array iterators.

 const std::array<const char*, Size> x;
 const auto end = x.begin() + N; // N is less than std::distance(x.begin(),
x.end());
 auto it = std::find(names.begin(), end, X);


--

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">In what way i=
s the current proposal going to be a problem for library authors?=20
<br>It&#39;s only about basic_string and vector, not your library.
<br></blockquote><div><br></div><div>I don&#39;t believe that it is a probl=
em for library authors, and is certainly not an issue for any library that =
I&#39;m writing.</div><div><br></div><div>My original concern was it potent=
ially resulting in APIs that are difficult to use for users. Concerns simil=
ar to this are not without precedent; for example=C2=A0http://wg21.cmeerw.n=
et/lwg/issue434, talks about how having the user supply template parameters=
 make the API hard to use. It was agreed that adding extra overloads to mak=
e it simpler to use was an improvement.</div><div><br></div><div>As a real =
world example, I have run into issues where code using the current standard=
 library failed to compile with very cryptic errors. All because that parti=
cular implementation chose to use plain pointers as the std::array iterator=
s.</div><div><br></div><div class=3D"prettyprint" style=3D"border: 1px soli=
d rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250=
, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font co=
lor=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
=C2=A0</span></font><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">array</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">char</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">*,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Size</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">end</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">begin</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> N</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// N is less than std::distance(x.begin(), x.end());</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> it </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">find</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>names</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">end</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> X</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span></div></code></div><div><div><br></div></div><div=
><br></div></div>

<p></p>

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

------=_Part_1299_975967649.1446765257147--
------=_Part_1298_1902974178.1446765257147--

.