Topic: std::adjacent_for_each Proposal Idea
Author: matthias.s.fuchs@gmail.com
Date: Mon, 12 Jun 2017 10:22:26 -0700 (PDT)
Raw View
------=_Part_573_1107576858.1497288146281
Content-Type: multipart/alternative;
boundary="----=_Part_574_2082754624.1497288146282"
------=_Part_574_2082754624.1497288146282
Content-Type: text/plain; charset="UTF-8"
Hi,
std::adjacent_for_each would apply the given function object to adjacent
elements of the sequence.
The implementation would be something like:
template<typename ForwardIt, typename BinaryFunction>
BinaryFunction(ForwardIt first, ForwardIt last, BinaryFunction f)
{
if (first == last)
return f;
ForwardIt adjacent = first;
++adjacent;
for (; adjacent != last; ++first, ++adjacent)
f(*first, *adjacent);
return f;
}
Would you have interest in me creating [1] an actual for adjacent_for_each?
The ExecutionPolicy-version would be similar to std::adjacent_find.
Just in case, I had the need for such a function multiple times.
Today once more.
I figure that other people might also be interested in this algorithm.
Best,
Matthias
[1] Well, first I'd have too look into the process of proposal submissions,
their styling, standardeese etc.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69825579-ee97-42cf-a883-147e90fcbdb3%40isocpp.org.
------=_Part_574_2082754624.1497288146282
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>std::adjacent_for_each would apply the given fu=
nction object to adjacent elements of the sequence.<br>The implementation w=
ould be something like:<br><br><div style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">ForwardIt</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">BinaryFunction</span><s=
pan 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">BinaryFunction</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">ForwardIt</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> first</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">ForwardIt</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">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: #606;" class=3D"styled-by-prettify">BinaryFunction</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">first </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">last</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Forwar=
dIt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> adjace=
nt </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> first</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">++</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">adjacent</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D"col=
or: #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"> adjacent </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">!=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">last</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">++</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=
: #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">adjacent</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 f</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(*</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">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: #660;" class=3D"styled-by-prettify=
">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">adjacen=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ret=
urn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
br><br>Would you have interest in me creating [1] an actual for adjacent_fo=
r_each?<br>The <span class=3D"mw-geshi cpp source-cpp">ExecutionPolicy-vers=
ion would be similar to std::adjacent_find.<br><br>Just in case, I had the =
need for such a function multiple times.<br>Today once more.<br>I figure th=
at other people might also be interested in this algorithm.<br><br>Best,<br=
>Matthias<br></span><br>[1] Well, first I'd have too look into the proc=
ess of proposal submissions, their styling, standardeese etc.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/69825579-ee97-42cf-a883-147e90fcbdb3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/69825579-ee97-42cf-a883-147e90fcbdb3=
%40isocpp.org</a>.<br />
------=_Part_574_2082754624.1497288146282--
------=_Part_573_1107576858.1497288146281--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 12 Jun 2017 12:57:00 -0700
Raw View
--001a113a735e110e910551c8baeb
Content-Type: text/plain; charset="UTF-8"
On 12 June 2017 at 10:22, <matthias.s.fuchs@gmail.com> wrote:
> Hi,
>
> std::adjacent_for_each would apply the given function object to adjacent
> elements of the sequence.
> The implementation would be something like:
>
> template<typename ForwardIt, typename BinaryFunction>
> BinaryFunction(ForwardIt first, ForwardIt last, BinaryFunction f)
> {
> if (first == last)
> return f;
>
> ForwardIt adjacent = first;
> ++adjacent;
> for (; adjacent != last; ++first, ++adjacent)
> f(*first, *adjacent);
>
> return f;
> }
>
>
> Would you have interest in me creating [1] an actual for adjacent_for_each?
> The ExecutionPolicy-version would be similar to std::adjacent_find.
>
> Just in case, I had the need for such a function multiple times.
> Today once more.
> I figure that other people might also be interested in this algorithm.
>
I think it would be preferable to provide a range zip operation. Then
adjacent_for_each(range, f) is for_each(zip(tail(range), range), f).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnLPch4FEhmMpXeCd9937Rv_OB1G3qjCJQzk0tOE5Y_0Q%40mail.gmail.com.
--001a113a735e110e910551c8baeb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
2 June 2017 at 10:22, <span dir=3D"ltr"><<a href=3D"mailto:matthias.s.f=
uchs@gmail.com" target=3D"_blank">matthias.s.fuchs@gmail.com</a>></span>=
wrote:<br><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">Hi,<br><br>std::=
adjacent_for_each would apply the given function object to adjacent element=
s of the sequence.<br>The implementation would be something like:<br><br><d=
iv style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187)=
;border-style:solid;border-width:1px" class=3D"m_-6709395549329416278pretty=
print"><code class=3D"m_-6709395549329416278prettyprint"><div class=3D"m_-6=
709395549329416278subprettyprint"><span style=3D"color:#008" class=3D"m_-67=
09395549329416278styled-by-prettify">template</span><span style=3D"color:#6=
60" class=3D"m_-6709395549329416278styled-by-prettify"><</span><span sty=
le=3D"color:#008" class=3D"m_-6709395549329416278styled-by-prettify">typena=
me</span><span style=3D"color:#000" class=3D"m_-6709395549329416278styled-b=
y-prettify"> </span><span style=3D"color:#606" class=3D"m_-6709395549329416=
278styled-by-prettify">ForwardIt</span><span style=3D"color:#660" class=3D"=
m_-6709395549329416278styled-by-prettify">,</span><span style=3D"color:#000=
" class=3D"m_-6709395549329416278styled-by-prettify"> </span><span style=3D=
"color:#008" class=3D"m_-6709395549329416278styled-by-prettify">typename</s=
pan><span style=3D"color:#000" class=3D"m_-6709395549329416278styled-by-pre=
ttify"> </span><span style=3D"color:#606" class=3D"m_-6709395549329416278st=
yled-by-prettify">BinaryFunction</span><span style=3D"color:#660" class=3D"=
m_-6709395549329416278styled-by-prettify">></span><span style=3D"color:#=
000" class=3D"m_-6709395549329416278styled-by-prettify"><br></span><span st=
yle=3D"color:#606" class=3D"m_-6709395549329416278styled-by-prettify">Binar=
yFunction</span><span style=3D"color:#660" class=3D"m_-6709395549329416278s=
tyled-by-prettify">(</span><span style=3D"color:#606" class=3D"m_-670939554=
9329416278styled-by-prettify">ForwardIt</span><span style=3D"color:#000" cl=
ass=3D"m_-6709395549329416278styled-by-prettify"> first</span><span style=
=3D"color:#660" class=3D"m_-6709395549329416278styled-by-prettify">,</span>=
<span style=3D"color:#000" class=3D"m_-6709395549329416278styled-by-prettif=
y"> </span><span style=3D"color:#606" class=3D"m_-6709395549329416278styled=
-by-prettify">ForwardIt</span><span style=3D"color:#000" class=3D"m_-670939=
5549329416278styled-by-prettify"> </span><span style=3D"color:#008" class=
=3D"m_-6709395549329416278styled-by-prettify">last</span><span style=3D"col=
or:#660" class=3D"m_-6709395549329416278styled-by-prettify">,</span><span s=
tyle=3D"color:#000" class=3D"m_-6709395549329416278styled-by-prettify"> </s=
pan><span style=3D"color:#606" class=3D"m_-6709395549329416278styled-by-pre=
ttify">BinaryFunction</span><span style=3D"color:#000" class=3D"m_-67093955=
49329416278styled-by-prettify"> f</span><span style=3D"color:#660" class=3D=
"m_-6709395549329416278styled-by-prettify">)</span><span style=3D"color:#00=
0" class=3D"m_-6709395549329416278styled-by-prettify"><br></span><span styl=
e=3D"color:#660" class=3D"m_-6709395549329416278styled-by-prettify">{</span=
><span style=3D"color:#000" class=3D"m_-6709395549329416278styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_-6709395=
549329416278styled-by-prettify">if</span><span style=3D"color:#000" class=
=3D"m_-6709395549329416278styled-by-prettify"> </span><span style=3D"color:=
#660" class=3D"m_-6709395549329416278styled-by-prettify">(</span><span styl=
e=3D"color:#000" class=3D"m_-6709395549329416278styled-by-prettify">first <=
/span><span style=3D"color:#660" class=3D"m_-6709395549329416278styled-by-p=
rettify">=3D=3D</span><span style=3D"color:#000" class=3D"m_-67093955493294=
16278styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_-670=
9395549329416278styled-by-prettify">last</span><span style=3D"color:#660" c=
lass=3D"m_-6709395549329416278styled-by-prettify">)</span><span style=3D"co=
lor:#000" class=3D"m_-6709395549329416278styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_-67093955493=
29416278styled-by-prettify">return</span><span style=3D"color:#000" class=
=3D"m_-6709395549329416278styled-by-prettify"> f</span><span style=3D"color=
:#660" class=3D"m_-6709395549329416278styled-by-prettify">;</span><span sty=
le=3D"color:#000" class=3D"m_-6709395549329416278styled-by-prettify"><br><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:#606" class=3D"m_-6709395549329=
416278styled-by-prettify">ForwardIt</span><span style=3D"color:#000" class=
=3D"m_-6709395549329416278styled-by-prettify"> adjacent </span><span style=
=3D"color:#660" class=3D"m_-6709395549329416278styled-by-prettify">=3D</spa=
n><span style=3D"color:#000" class=3D"m_-6709395549329416278styled-by-prett=
ify"> first</span><span style=3D"color:#660" class=3D"m_-670939554932941627=
8styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_-6709395=
549329416278styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#660" class=3D"m_-6709395549329416278styled-by-prettify">++</span><span =
style=3D"color:#000" class=3D"m_-6709395549329416278styled-by-prettify">adj=
acent</span><span style=3D"color:#660" class=3D"m_-6709395549329416278style=
d-by-prettify">;</span><span style=3D"color:#000" class=3D"m_-6709395549329=
416278styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#00=
8" class=3D"m_-6709395549329416278styled-by-prettify">for</span><span style=
=3D"color:#000" class=3D"m_-6709395549329416278styled-by-prettify"> </span>=
<span style=3D"color:#660" class=3D"m_-6709395549329416278styled-by-prettif=
y">(;</span><span style=3D"color:#000" class=3D"m_-6709395549329416278style=
d-by-prettify"> adjacent </span><span style=3D"color:#660" class=3D"m_-6709=
395549329416278styled-by-prettify">!=3D</span><span style=3D"color:#000" cl=
ass=3D"m_-6709395549329416278styled-by-prettify"> </span><span style=3D"col=
or:#008" class=3D"m_-6709395549329416278styled-by-prettify">last</span><spa=
n style=3D"color:#660" class=3D"m_-6709395549329416278styled-by-prettify">;=
</span><span style=3D"color:#000" class=3D"m_-6709395549329416278styled-by-=
prettify"> </span><span style=3D"color:#660" class=3D"m_-670939554932941627=
8styled-by-prettify">++</span><span style=3D"color:#000" class=3D"m_-670939=
5549329416278styled-by-prettify">first</span><span style=3D"color:#660" cla=
ss=3D"m_-6709395549329416278styled-by-prettify">,</span><span style=3D"colo=
r:#000" class=3D"m_-6709395549329416278styled-by-prettify"> </span><span st=
yle=3D"color:#660" class=3D"m_-6709395549329416278styled-by-prettify">++</s=
pan><span style=3D"color:#000" class=3D"m_-6709395549329416278styled-by-pre=
ttify">adjacent</span><span style=3D"color:#660" class=3D"m_-67093955493294=
16278styled-by-prettify">)</span><span style=3D"color:#000" class=3D"m_-670=
9395549329416278styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 f</span=
><span style=3D"color:#660" class=3D"m_-6709395549329416278styled-by-pretti=
fy">(*</span><span style=3D"color:#000" class=3D"m_-6709395549329416278styl=
ed-by-prettify">first</span><span style=3D"color:#660" class=3D"m_-67093955=
49329416278styled-by-prettify">,</span><span style=3D"color:#000" class=3D"=
m_-6709395549329416278styled-by-prettify"> </span><span style=3D"color:#660=
" class=3D"m_-6709395549329416278styled-by-prettify">*</span><span style=3D=
"color:#000" class=3D"m_-6709395549329416278styled-by-prettify">adjacent</s=
pan><span style=3D"color:#660" class=3D"m_-6709395549329416278styled-by-pre=
ttify">);</span><span style=3D"color:#000" class=3D"m_-6709395549329416278s=
tyled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008" =
class=3D"m_-6709395549329416278styled-by-prettify">return</span><span style=
=3D"color:#000" class=3D"m_-6709395549329416278styled-by-prettify"> f</span=
><span style=3D"color:#660" class=3D"m_-6709395549329416278styled-by-pretti=
fy">;</span><span style=3D"color:#000" class=3D"m_-6709395549329416278style=
d-by-prettify"><br></span><span style=3D"color:#660" class=3D"m_-6709395549=
329416278styled-by-prettify">}</span></div></code></div><br><br>Would you h=
ave interest in me creating [1] an actual for adjacent_for_each?<br>The <sp=
an class=3D"m_-6709395549329416278mw-geshi m_-6709395549329416278cpp m_-670=
9395549329416278source-cpp">ExecutionPolicy-version would be similar to std=
::adjacent_find.<br><br>Just in case, I had the need for such a function mu=
ltiple times.<br>Today once more.<br>I figure that other people might also =
be interested in this algorithm.</span></div></blockquote><div><br></div><d=
iv>I think it would be preferable to provide a range zip operation. Then ad=
jacent_for_each(range, f) is for_each(zip(tail(range), range), f).=C2=A0</d=
iv></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnLPch4FEhmMpXeCd9937Rv_OB1G3qj=
CJQzk0tOE5Y_0Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnLPch4FEhm=
MpXeCd9937Rv_OB1G3qjCJQzk0tOE5Y_0Q%40mail.gmail.com</a>.<br />
--001a113a735e110e910551c8baeb--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 12 Jun 2017 14:57:57 -0700 (PDT)
Raw View
------=_Part_3501_1290268628.1497304677705
Content-Type: multipart/alternative;
boundary="----=_Part_3502_855454249.1497304677706"
------=_Part_3502_855454249.1497304677706
Content-Type: text/plain; charset="UTF-8"
On Monday, June 12, 2017 at 3:57:23 PM UTC-4, Richard Smith wrote:
>
> On 12 June 2017 at 10:22, <matthias...@gmail.com <javascript:>> wrote:
>
>> Hi,
>>
>> std::adjacent_for_each would apply the given function object to adjacent
>> elements of the sequence.
>> The implementation would be something like:
>>
>> template<typename ForwardIt, typename BinaryFunction>
>> BinaryFunction(ForwardIt first, ForwardIt last, BinaryFunction f)
>> {
>> if (first == last)
>> return f;
>>
>> ForwardIt adjacent = first;
>> ++adjacent;
>> for (; adjacent != last; ++first, ++adjacent)
>> f(*first, *adjacent);
>>
>> return f;
>> }
>>
>>
>> Would you have interest in me creating [1] an actual for
>> adjacent_for_each?
>> The ExecutionPolicy-version would be similar to std::adjacent_find.
>>
>> Just in case, I had the need for such a function multiple times.
>> Today once more.
>> I figure that other people might also be interested in this algorithm.
>>
>
> I think it would be preferable to provide a range zip operation. Then
> adjacent_for_each(range, f) is for_each(zip(tail(range), range), f).
>
I have no idea what "for_each(zip(tail(range), range), f)" does. Also, if
it does what I think it does, then you put `tail(range)` in the wrong place.
While I'm all for having zip iterators/ranges and such, having an easily
comprehensible named algorithm for such things is good too, even if it is
implemented exactly like that.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ef7ff0a8-bf19-4fde-94f9-2cb713ade687%40isocpp.org.
------=_Part_3502_855454249.1497304677706
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, June 12, 2017 at 3:57:23 PM UTC-4, Rich=
ard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote">On 12 June 2017 at 10:22, <span dir=3D"=
ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"Xwum5RCHAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">matthias...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">Hi,<br><br>std::adjacent_for_each would apply the g=
iven function object to adjacent elements of the sequence.<br>The implement=
ation would be something like:<br><br><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x"><code><div><span style=3D"color:#008">template</span><span style=3D"colo=
r:#660"><</span><span style=3D"color:#008">typename</span><span style=3D=
"color:#000"> </span><span style=3D"color:#606">ForwardIt</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">typename</span><span style=3D"color:#000"> </span><span style=3D=
"color:#606">BinaryFunction</span><span style=3D"color:#660">></span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#606">BinaryFunctio=
n</span><span style=3D"color:#660">(</span><span style=3D"color:#606">Forwa=
rdIt</span><span style=3D"color:#000"> first</span><span style=3D"color:#66=
0">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Fo=
rwardIt</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>last</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> =
</span><span style=3D"color:#606">BinaryFunction</span><span style=3D"color=
:#000"> f</span><span style=3D"color:#660">)</span><span style=3D"color:#00=
0"><br></span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">if</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">first </span><span style=3D"color:#660">=3D=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">last</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0=
=C2=A0 </span><span style=3D"color:#008">return</span><span style=3D"color=
:#000"> f</span><span style=3D"color:#660">;</span><span style=3D"color:#00=
0"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#606">ForwardIt</span>=
<span style=3D"color:#000"> adjacent </span><span style=3D"color:#660">=3D<=
/span><span style=3D"color:#000"> first</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor:#660">++</span><span style=3D"color:#000">adjacent</span><span style=3D=
"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><s=
pan style=3D"color:#008">for</span><span style=3D"color:#000"> </span><span=
style=3D"color:#660">(;</span><span style=3D"color:#000"> adjacent </span>=
<span style=3D"color:#660">!=3D</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#008">last</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">++</span><span st=
yle=3D"color:#000">first</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">++</span><span style=
=3D"color:#000">adjacent</span><span style=3D"color:#660">)</span><span sty=
le=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 f</span><span style=3D"co=
lor:#660">(*</span><span style=3D"color:#000">first</span><span style=3D"co=
lor:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">*</span><span style=3D"color:#000">adjacent</span><span style=3D"color=
:#660">);</span><span style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color:#008">return</span><span style=3D"color:#000"> f</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">}</span></div></code></div><br><br>Would you have in=
terest in me creating [1] an actual for adjacent_for_each?<br>The <span>Exe=
cutionPolicy-version would be similar to std::adjacent_find.<br><br>Just in=
case, I had the need for such a function multiple times.<br>Today once mor=
e.<br>I figure that other people might also be interested in this algorithm=
..</span></div></blockquote><div><br></div><div>I think it would be preferab=
le to provide a range zip operation. Then adjacent_for_each(range, f) is fo=
r_each(zip(tail(range), range), f).</div></div></div></div></blockquote><di=
v><br>I have no idea what "for_each(zip(tail(range), range), f)" =
does. Also, if it does what I think it does, then you put `tail(range)` in =
the wrong place.<br><br>While I'm all for having zip iterators/ranges a=
nd such, having an easily comprehensible named algorithm for such things is=
good too, even if it is implemented exactly like that.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ef7ff0a8-bf19-4fde-94f9-2cb713ade687%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef7ff0a8-bf19-4fde-94f9-2cb713ade687=
%40isocpp.org</a>.<br />
------=_Part_3502_855454249.1497304677706--
------=_Part_3501_1290268628.1497304677705--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 12 Jun 2017 15:12:05 -0700
Raw View
--001a114fee302ad65f0551ca9d77
Content-Type: text/plain; charset="UTF-8"
On 12 June 2017 at 14:57, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Monday, June 12, 2017 at 3:57:23 PM UTC-4, Richard Smith wrote:
>>
>> On 12 June 2017 at 10:22, <matthias...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> std::adjacent_for_each would apply the given function object to adjacent
>>> elements of the sequence.
>>> The implementation would be something like:
>>>
>>> template<typename ForwardIt, typename BinaryFunction>
>>> BinaryFunction(ForwardIt first, ForwardIt last, BinaryFunction f)
>>> {
>>> if (first == last)
>>> return f;
>>>
>>> ForwardIt adjacent = first;
>>> ++adjacent;
>>> for (; adjacent != last; ++first, ++adjacent)
>>> f(*first, *adjacent);
>>>
>>> return f;
>>> }
>>>
>>>
>>> Would you have interest in me creating [1] an actual for
>>> adjacent_for_each?
>>> The ExecutionPolicy-version would be similar to std::adjacent_find.
>>>
>>> Just in case, I had the need for such a function multiple times.
>>> Today once more.
>>> I figure that other people might also be interested in this algorithm.
>>>
>>
>> I think it would be preferable to provide a range zip operation. Then
>> adjacent_for_each(range, f) is for_each(zip(tail(range), range), f).
>>
>
> I have no idea what "for_each(zip(tail(range), range), f)" does. Also, if
> it does what I think it does, then you put `tail(range)` in the wrong place.
>
I did, but I noticed seconds after sending this and it didn't seem worth
sending an erratum (it's not wrong, just a strange argument order...).
While I'm all for having zip iterators/ranges and such, having an easily
> comprehensible named algorithm for such things is good too, even if it is
> implemented exactly like that.
>
The counterargument would be that including uncommon algorithms such as
this one would lead to a very large and cluttered standard library. (What
about a for_each that gives consecutive 3-tuples of elements? What about a
version that gives me each element i and element i + j, for some j passed
at runtime? And so on.)
So I'd generally favour adding primitive algorithms from which other
algorithms can be constructed. That doesn't mean we shouldn't have
algorithms such as adjacent_for_each, but it does mean that they need to be
sufficiently commonly used and/or hard to get right to justify their
inclusion. Personally, I would want to a paper proposing this algorithm to
include examples of cases where it would be used, to help judge its merits,
as I can't say I've often seen need for this in the code that I interact
with.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkiUL8Wq004JCdz4WT3xYXTjVT%2B_2FTjUoHxGxOtYar%3Dg%40mail.gmail.com.
--001a114fee302ad65f0551ca9d77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
2 June 2017 at 14:57, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, June 12,=
2017 at 3:57:23 PM UTC-4, Richard Smith wrote:<span class=3D""><blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e">On 12 June 2017 at 10:22, <span dir=3D"ltr"><<a rel=3D"nofollow">mat=
thias...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">Hi,<br><br>std::adjacent_for_each would apply the given fu=
nction object to adjacent elements of the sequence.<br>The implementation w=
ould be something like:<br><br><div style=3D"background-color:rgb(250,250,2=
50);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><cod=
e><div><span style=3D"color:#008">template</span><span style=3D"color:#660"=
><</span><span style=3D"color:#008">typename</span><span style=3D"color:=
#000"> </span><span style=3D"color:#606">ForwardIt</span><span style=3D"col=
or:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
08">typename</span><span style=3D"color:#000"> </span><span style=3D"color:=
#606">BinaryFunction</span><span style=3D"color:#660">></span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#606">BinaryFunction</span=
><span style=3D"color:#660">(</span><span style=3D"color:#606">ForwardIt</s=
pan><span style=3D"color:#000"> first</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#606">ForwardIt=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">last</=
span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#606">BinaryFunction</span><span style=3D"color:#000">=
f</span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br>=
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#008">if</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">(</span><span style=3D"color:#0=
00">first </span><span style=3D"color:#660">=3D=3D</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#008">last</span><span style=3D"color=
:#660">)</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:#008">return</span><span style=3D"color:#000"> f=
</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:#606">ForwardIt</span><span sty=
le=3D"color:#000"> adjacent </span><span style=3D"color:#660">=3D</span><sp=
an style=3D"color:#000"> first</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660"=
>++</span><span style=3D"color:#000">adjacent</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">for</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">(;</span><span style=3D"color:#000"> adjacent </span><span sty=
le=3D"color:#660">!=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">last</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">++</span><span style=3D"=
color:#000">first</span><span style=3D"color:#660">,</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">++</span><span style=3D"color=
:#000">adjacent</span><span style=3D"color:#660">)</span><span style=3D"col=
or:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 f</span><span style=3D"color:#660"=
>(*</span><span style=3D"color:#000">first</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"> </span><span style=3D"color:#660">*</s=
pan><span style=3D"color:#000">adjacent</span><span style=3D"color:#660">);=
</span><span style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">return</span><span style=3D"color:#000"> f</span><span styl=
e=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">}</span></div></code></div><br><br>Would you have interest =
in me creating [1] an actual for adjacent_for_each?<br>The <span>ExecutionP=
olicy-version would be similar to std::adjacent_find.<br><br>Just in case, =
I had the need for such a function multiple times.<br>Today once more.<br>I=
figure that other people might also be interested in this algorithm.</span=
></div></blockquote><div><br></div><div>I think it would be preferable to p=
rovide a range zip operation. Then adjacent_for_each(range, f) is for_each(=
zip(tail(range), range), f).</div></div></div></div></blockquote></span><di=
v><br>I have no idea what "for_each(zip(tail(range), range), f)" =
does. Also, if it does what I think it does, then you put `tail(range)` in =
the wrong place.<br></div></div></blockquote><div><br></div><div>I did, but=
I noticed seconds after sending this and it didn't seem worth sending =
an erratum (it's not wrong, just a strange argument order...).</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>While I=
9;m all for having zip iterators/ranges and such, having an easily comprehe=
nsible named algorithm for such things is good too, even if it is implement=
ed exactly like that.</div></div></blockquote><div><br></div><div>The count=
erargument would be that including uncommon algorithms such as this one wou=
ld lead to a very large and cluttered standard library. (What about a for_e=
ach that gives consecutive 3-tuples of elements? What about a version that =
gives me each element i and element i + j, for some j passed at runtime? An=
d so on.)</div><div><br></div><div>So I'd generally favour adding primi=
tive algorithms from which other algorithms can be constructed. That doesn&=
#39;t mean we shouldn't have algorithms such as adjacent_for_each, but =
it does mean that they need to be sufficiently commonly used and/or hard to=
get right to justify their inclusion. Personally, I would want to a paper =
proposing this algorithm to include examples of cases where it would be use=
d, to help judge its merits, as I can't say I've often seen need fo=
r this in the code that I interact with.</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkiUL8Wq004JCdz4WT3xYXTjVT%2B_2=
FTjUoHxGxOtYar%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkiUL8W=
q004JCdz4WT3xYXTjVT%2B_2FTjUoHxGxOtYar%3Dg%40mail.gmail.com</a>.<br />
--001a114fee302ad65f0551ca9d77--
.
Author: Mathias Gaunard <mathias@gaunard.com>
Date: Mon, 12 Jun 2017 23:12:50 +0100
Raw View
--f403045eae30a7eb130551ca9efe
Content-Type: text/plain; charset="UTF-8"
On 12 June 2017 at 22:57, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Monday, June 12, 2017 at 3:57:23 PM UTC-4, Richard Smith wrote:
>>
>> On 12 June 2017 at 10:22, <matthias...@gmail.com> wrote:
>>
>>>
>>> I think it would be preferable to provide a range zip operation. Then
>> adjacent_for_each(range, f) is for_each(zip(tail(range), range), f).
>>
>
> I have no idea what "for_each(zip(tail(range), range), f)" does. Also, if
> it does what I think it does, then you put `tail(range)` in the wrong place.
>
I'd expect to get an error, since tail(range) and range are not the same
size.
I don't think it's sensible for zip to take the minimum size.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-QFJJr4G319Oe-v6Tfhd1WOHvxm_EHuEeQ61N%2BQvL5LQ%40mail.gmail.com.
--f403045eae30a7eb130551ca9efe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
2 June 2017 at 22:57, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, =
June 12, 2017 at 3:57:23 PM UTC-4, Richard Smith wrote:<span class=3D""><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote">On 12 June 2017 at 10:22, <span dir=3D"ltr"><<a rel=3D"nofol=
low">matthias...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br></div></blockquote><div>I think it would be pr=
eferable to provide a range zip operation. Then adjacent_for_each(range, f)=
is for_each(zip(tail(range), range), f).</div></div></div></div></blockquo=
te></span><div><br>I have no idea what "for_each(zip(tail(range), rang=
e), f)" does. Also, if it does what I think it does, then you put `tai=
l(range)` in the wrong place.<br></div></div></blockquote><div><br></div><d=
iv>I'd expect to get an error, since tail(range) and range are not the =
same size.</div><div>I don't think it's sensible for zip to take th=
e minimum size.</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya-QFJJr4G319Oe-v6Tfhd1WOHvxm_EH=
uEeQ61N%2BQvL5LQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-QFJJr4G=
319Oe-v6Tfhd1WOHvxm_EHuEeQ61N%2BQvL5LQ%40mail.gmail.com</a>.<br />
--f403045eae30a7eb130551ca9efe--
.
Author: Mathias Gaunard <mathias@gaunard.com>
Date: Mon, 12 Jun 2017 23:17:12 +0100
Raw View
--001a1143f2f24311c70551caaefe
Content-Type: text/plain; charset="UTF-8"
On 12 June 2017 at 23:12, Richard Smith <richard@metafoo.co.uk> wrote:
>
> The counterargument would be that including uncommon algorithms such as
> this one would lead to a very large and cluttered standard library. (What
> about a for_each that gives consecutive 3-tuples of elements? What about a
> version that gives me each element i and element i + j, for some j passed
> at runtime? And so on.)
>
Stencils are some of the most common numerical building blocks, and can be
implemented much more efficiently than zips of indexed or shifted ranges.
They are in my opinion to correct abstraction to replace this and
adjacent_difference.
The problem is that the standard algorithms are limited to 1D, and while 1D
stencils are useful, they're not nearly as interesting as 2D or 3D ones.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_BBvGWq5%2BWik_XZg09vhn91nC3ctmDB0PyuLx14VPxEw%40mail.gmail.com.
--001a1143f2f24311c70551caaefe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
2 June 2017 at 23:12, Richard Smith <span dir=3D"ltr"><<a href=3D"mailto=
:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>></sp=
an> 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"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><div><br></div></=
span><div>The counterargument would be that including uncommon algorithms s=
uch as this one would lead to a very large and cluttered standard library. =
(What about a for_each that gives consecutive 3-tuples of elements? What ab=
out a version that gives me each element i and element i + j, for some j pa=
ssed at runtime? And so on.)</div></div></div></div></blockquote><div><br><=
/div><div>Stencils are some of the most common numerical building blocks, a=
nd can be implemented much more efficiently than zips of indexed or shifted=
ranges.</div><div>They are in my opinion to correct abstraction to replace=
this and adjacent_difference.</div><div><br></div><div>The problem is that=
the standard algorithms are limited to 1D, and while 1D stencils are usefu=
l, they're not nearly as interesting as 2D or 3D ones.</div></div></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya_BBvGWq5%2BWik_XZg09vhn91nC3ct=
mDB0PyuLx14VPxEw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_BBvGWq5=
%2BWik_XZg09vhn91nC3ctmDB0PyuLx14VPxEw%40mail.gmail.com</a>.<br />
--001a1143f2f24311c70551caaefe--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 12 Jun 2017 15:32:21 -0700
Raw View
--001a114f3fb0ab3bb70551cae55a
Content-Type: text/plain; charset="UTF-8"
On 12 June 2017 at 15:12, Mathias Gaunard <mathias@gaunard.com> wrote:
> On 12 June 2017 at 22:57, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> On Monday, June 12, 2017 at 3:57:23 PM UTC-4, Richard Smith wrote:
>>>
>>> On 12 June 2017 at 10:22, <matthias...@gmail.com> wrote:
>>>
>>>>
>>>> I think it would be preferable to provide a range zip operation. Then
>>> adjacent_for_each(range, f) is for_each(zip(tail(range), range), f).
>>>
>>
>> I have no idea what "for_each(zip(tail(range), range), f)" does. Also, if
>> it does what I think it does, then you put `tail(range)` in the wrong place.
>>
>
> I'd expect to get an error, since tail(range) and range are not the same
> size.
> I don't think it's sensible for zip to take the minimum size.
>
You should take this up with Eric Niebler; his range-v3 library takes the
smaller size:
https://github.com/ericniebler/range-v3/blob/master/include/range/v3/view/zip_with.hpp#L193
-- and it's not unreasonable to expect this to arrive in the Ranges TS at
some point.
(Python's zip also takes the length of the shortest sequence:
https://docs.python.org/3/library/functions.html#zip)
(Haskell's zip also takes the length of the shortest sequence:
http://zvon.org/other/haskell/Outputprelude/zip_f.html)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnQCavueA%3DM6aBU1Kx57iEjWyuuXBT%2B2zrvE%3DGn%3D-yLEA%40mail.gmail.com.
--001a114f3fb0ab3bb70551cae55a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
2 June 2017 at 15:12, Mathias Gaunard <span dir=3D"ltr"><<a href=3D"mail=
to:mathias@gaunard.com" target=3D"_blank">mathias@gaunard.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"gm=
ail-">On 12 June 2017 at 22:57, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br></span><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><span class=3D"gmail-"><br><br>On Monday, June 12, 2017 =
at 3:57:23 PM UTC-4, Richard Smith wrote:</span><span><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><span class=3D"gmail-">On 12 June 2017 at 10:22, <span dir=3D"ltr"><=
<a rel=3D"nofollow">matthias...@gmail.com</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br></div></bloc=
kquote></span><span class=3D"gmail-"><div>I think it would be preferable to=
provide a range zip operation. Then adjacent_for_each(range, f) is for_eac=
h(zip(tail(range), range), f).</div></span></div></div></div></blockquote><=
/span><span class=3D"gmail-"><div><br>I have no idea what "for_each(zi=
p(tail(range), range), f)" does. Also, if it does what I think it does=
, then you put `tail(range)` in the wrong place.<br></div></span></div></bl=
ockquote><div><br></div><div>I'd expect to get an error, since tail(ran=
ge) and range are not the same size.</div><div>I don't think it's s=
ensible for zip to take the minimum size.</div></div></div></div></blockquo=
te><div><br></div><div>You should take this up with Eric Niebler; his range=
-v3 library takes the smaller size:=C2=A0<a href=3D"https://github.com/eric=
niebler/range-v3/blob/master/include/range/v3/view/zip_with.hpp#L193">https=
://github.com/ericniebler/range-v3/blob/master/include/range/v3/view/zip_wi=
th.hpp#L193</a> -- and it's not unreasonable to expect this to arrive i=
n the Ranges TS at some point.</div><div><br></div><div>(Python's zip a=
lso takes the length of the shortest sequence:=C2=A0<a href=3D"https://docs=
..python.org/3/library/functions.html#zip">https://docs.python.org/3/library=
/functions.html#zip</a>)</div><div>(Haskell's zip=C2=A0also takes the l=
ength of the shortest sequence:=C2=A0<a href=3D"http://zvon.org/other/haske=
ll/Outputprelude/zip_f.html">http://zvon.org/other/haskell/Outputprelude/zi=
p_f.html</a>)</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnQCavueA%3DM6aBU1Kx57iEjWyuuXB=
T%2B2zrvE%3DGn%3D-yLEA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnQ=
CavueA%3DM6aBU1Kx57iEjWyuuXBT%2B2zrvE%3DGn%3D-yLEA%40mail.gmail.com</a>.<br=
/>
--001a114f3fb0ab3bb70551cae55a--
.
Author: Akira Takahashi <faithandbrave@gmail.com>
Date: Tue, 13 Jun 2017 14:12:48 +0900
Raw View
--001a1146a3ec9450510551d07cb0
Content-Type: text/plain; charset="UTF-8"
Hi,
2017-06-13 2:22 GMT+09:00 <matthias.s.fuchs@gmail.com>:
> Hi,
>
> std::adjacent_for_each would apply the given function object to adjacent
> elements of the sequence.
> The implementation would be something like:
>
FYI, my `adjacent_for_each()` implementation is here (range version):
https://gist.github.com/faithandbrave/370155a2078b158853b3
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAED3xEiuGbUxEpycrVWpu8JE9P2uwF8uwkMiztr7m3MYN8Hzqw%40mail.gmail.com.
--001a1146a3ec9450510551d07cb0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">2017-06-13 2:22 GMT+09:00 <span dir=3D"ltr"><<a href=3D"mailto:m=
atthias.s.fuchs@gmail.com" target=3D"_blank">matthias.s.fuchs@gmail.com</a>=
></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">Hi,<br><br>std::adjacent_for_each would apply the given function o=
bject to adjacent elements of the sequence.<br>The implementation would be =
something like:</div></blockquote><div><br></div><div>=C2=A0</div></div>FYI=
, my `adjacent_for_each()` implementation is here (range version):</div><di=
v class=3D"gmail_extra"><a href=3D"https://gist.github.com/faithandbrave/37=
0155a2078b158853b3">https://gist.github.com/faithandbrave/370155a2078b15885=
3b3</a><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAED3xEiuGbUxEpycrVWpu8JE9P2uwF8uwkMi=
ztr7m3MYN8Hzqw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAED3xEiuGbUxEpyc=
rVWpu8JE9P2uwF8uwkMiztr7m3MYN8Hzqw%40mail.gmail.com</a>.<br />
--001a1146a3ec9450510551d07cb0--
.
Author: Mathias Gaunard <mathias.gaunard@gmail.com>
Date: Tue, 13 Jun 2017 08:38:54 +0100
Raw View
--f403045eae3013288c0551d287fe
Content-Type: text/plain; charset="UTF-8"
On 12 Jun 2017 11:32 pm, "Richard Smith" <richard@metafoo.co.uk> wrote:
On 12 June 2017 at 15:12, Mathias Gaunard <mathias@gaunard.com> wrote:
> On 12 June 2017 at 22:57, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> On Monday, June 12, 2017 at 3:57:23 PM UTC-4, Richard Smith wrote:
>>>
>>> On 12 June 2017 at 10:22, <matthias...@gmail.com> wrote:
>>>
>>>>
>>>> I think it would be preferable to provide a range zip operation. Then
>>> adjacent_for_each(range, f) is for_each(zip(tail(range), range), f).
>>>
>>
>> I have no idea what "for_each(zip(tail(range), range), f)" does. Also, if
>> it does what I think it does, then you put `tail(range)` in the wrong place.
>>
>
> I'd expect to get an error, since tail(range) and range are not the same
> size.
> I don't think it's sensible for zip to take the minimum size.
>
You should take this up with Eric Niebler; his range-v3 library takes the
smaller size: https://github.com/ericniebler/range-v3/blob/master/
include/range/v3/view/zip_with.hpp#L193 -- and it's not unreasonable to
expect this to arrive in the Ranges TS at some point.
There are quite a few things I don't like about range v3, I'm sure we'll
have the opportunity to bikeshed about it on the committee.
(Python's zip also takes the length of the shortest sequence:
https://docs.python.org/3/library/functions.html#zip)
(Haskell's zip also takes the length of the shortest sequence:
http://zvon.org/other/haskell/Outputprelude/zip_f.html)
While that is good justification, I'm worried about silently dropping
elements from a sequence.
It wouldn't be difficult to be explicit about removing the last element of
the range, or concatenating the other range with some dummy value.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya87%3DaW8rxfFTHLbk-YeL%3DqpgzioCSLvE3z5c3jQ27GnNQ%40mail.gmail.com.
--f403045eae3013288c0551d287fe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 12 Jun 2017 11:32 pm, "Richard Smith" <<a href=3D"mailto:=
richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>> wrot=
e:<br type=3D"attribution"><blockquote class=3D"m_-945185604854300580quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div c=
lass=3D"m_-945185604854300580elided-text">On 12 June 2017 at 15:12, Mathias=
Gaunard <span dir=3D"ltr"><<a href=3D"mailto:mathias@gaunard.com" targe=
t=3D"_blank">mathias@gaunard.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><span class=3D"m_-945185604854300580m_-1799384=
524084312081gmail-">On 12 June 2017 at 22:57, Nicol Bolas <span dir=3D"ltr"=
><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gma=
il.com</a>></span> wrote:<br></span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><span class=3D"m_-945185604854300580m_-17993=
84524084312081gmail-"><br><br>On Monday, June 12, 2017 at 3:57:23 PM UTC-4,=
Richard Smith wrote:</span><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span class=3D"=
m_-945185604854300580m_-1799384524084312081gmail-">On 12 June 2017 at 10:22=
, <span dir=3D"ltr"><<a rel=3D"nofollow">matthias...@gmail.com</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><br></div></blockquote></span><span class=3D"m_-945185604854300580=
m_-1799384524084312081gmail-"><div>I think it would be preferable to provid=
e a range zip operation. Then adjacent_for_each(range, f) is for_each(zip(t=
ail(range), range), f).</div></span></div></div></div></blockquote></span><=
span class=3D"m_-945185604854300580m_-1799384524084312081gmail-"><div><br>I=
have no idea what "for_each(zip(tail(range), range), f)" does. A=
lso, if it does what I think it does, then you put `tail(range)` in the wro=
ng place.<br></div></span></div></blockquote><div><br></div><div>I'd ex=
pect to get an error, since tail(range) and range are not the same size.</d=
iv><div>I don't think it's sensible for zip to take the minimum siz=
e.</div></div></div></div></blockquote><div><br></div></div><div>You should=
take this up with Eric Niebler; his range-v3 library takes the smaller siz=
e:=C2=A0<a href=3D"https://github.com/ericniebler/range-v3/blob/master/incl=
ude/range/v3/view/zip_with.hpp#L193" target=3D"_blank">https://github.com/e=
ricn<wbr>iebler/range-v3/blob/master/<wbr>include/range/v3/view/zip_<wbr>wi=
th.hpp#L193</a> -- and it's not unreasonable to expect this to arrive i=
n the Ranges TS at some point.</div></div></div></div></blockquote></div></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><span style=3D"font=
-family:sans-serif">There are quite a few things I don't like about ran=
ge v3, I'm sure we'll have the opportunity to bikeshed about it on =
the committee.</span><br></div><div dir=3D"auto"><span style=3D"font-family=
:sans-serif"><br></span></div><div dir=3D"auto"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"m_-945185604854300580quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><=
br></div><div>(Python's zip also takes the length of the shortest seque=
nce:=C2=A0<a href=3D"https://docs.python.org/3/library/functions.html#zip" =
target=3D"_blank">https://docs.python.<wbr>org/3/library/functions.html#z<w=
br>ip</a>)</div><div>(Haskell's zip=C2=A0also takes the length of the s=
hortest sequence:=C2=A0<a href=3D"http://zvon.org/other/haskell/Outputprelu=
de/zip_f.html" target=3D"_blank">http://zvon.org/othe<wbr>r/haskell/Outputp=
relude/zip_f.<wbr>html</a>)</div></div></div></div></blockquote></div></div=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">While that is good jus=
tification, I'm worried about silently dropping elements from a sequenc=
e.</div><div dir=3D"auto">It wouldn't be difficult to be explicit about=
removing the last element of the range, or concatenating the other range w=
ith some dummy value.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya87%3DaW8rxfFTHLbk-YeL%3Dqpgzio=
CSLvE3z5c3jQ27GnNQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya87%3Da=
W8rxfFTHLbk-YeL%3DqpgzioCSLvE3z5c3jQ27GnNQ%40mail.gmail.com</a>.<br />
--f403045eae3013288c0551d287fe--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Tue, 13 Jun 2017 08:32:12 +0000
Raw View
--f403045f8d944ebb500551d3465d
Content-Type: text/plain; charset="UTF-8"
On Tue, Jun 13, 2017 at 9:38 AM Mathias Gaunard <mathias.gaunard@gmail.com>
wrote:
> On 12 Jun 2017 11:32 pm, "Richard Smith" <richard@metafoo.co.uk> wrote:
>
> On 12 June 2017 at 15:12, Mathias Gaunard <mathias@gaunard.com> wrote:
>
>> On 12 June 2017 at 22:57, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>>
>>>
>>> On Monday, June 12, 2017 at 3:57:23 PM UTC-4, Richard Smith wrote:
>>>>
>>>> On 12 June 2017 at 10:22, <matthias...@gmail.com> wrote:
>>>>
>>>>>
>>>>> I think it would be preferable to provide a range zip operation. Then
>>>> adjacent_for_each(range, f) is for_each(zip(tail(range), range), f).
>>>>
>>>
>>> I have no idea what "for_each(zip(tail(range), range), f)" does. Also,
>>> if it does what I think it does, then you put `tail(range)` in the wrong
>>> place.
>>>
>>
>> I'd expect to get an error, since tail(range) and range are not the same
>> size.
>> I don't think it's sensible for zip to take the minimum size.
>>
>
> You should take this up with Eric Niebler; his range-v3 library takes the
> smaller size:
> https://github.com/ericniebler/range-v3/blob/master/include/range/v3/view/zip_with.hpp#L193
> -- and it's not unreasonable to expect this to arrive in the Ranges TS at
> some point.
>
>
> There are quite a few things I don't like about range v3, I'm sure we'll
> have the opportunity to bikeshed about it on the committee.
>
>
> (Python's zip also takes the length of the shortest sequence:
> https://docs.python.org/3/library/functions.html#zip)
> (Haskell's zip also takes the length of the shortest sequence:
> http://zvon.org/other/haskell/Outputprelude/zip_f.html)
>
>
> While that is good justification, I'm worried about silently dropping
> elements from a sequence.
> It wouldn't be difficult to be explicit about removing the last element of
> the range, or concatenating the other range with some dummy value.
>
Do we *really *need to do everything differently than all the other
languages in the world, inventing dubious reasons to diverge? What exactly
is your goal? Is it to make it harder to migrate between languages by
making facilities with the exact same names behave slightly differently?
Similarly to explicitly dropping it, it wouldn't be hard to also have
`zip_exact` or whatever to have the semantics that differ from other
languages' `zip`.
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya87%3DaW8rxfFTHLbk-YeL%3DqpgzioCSLvE3z5c3jQ27GnNQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya87%3DaW8rxfFTHLbk-YeL%3DqpgzioCSLvE3z5c3jQ27GnNQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTo3gHxFz5iDSouvgOGNq02Mbs0wZybm3HL4viLtLrRAA%40mail.gmail.com.
--f403045f8d944ebb500551d3465d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 13=
, 2017 at 9:38 AM Mathias Gaunard <<a href=3D"mailto:mathias.gaunard@gma=
il.com">mathias.gaunard@gmail.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">On 12 Jun 2017 11:32 pm, "Richard Smith" <<a =
href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.=
uk</a>> wrote:<br type=3D"attribution"><blockquote class=3D"m_-730181850=
4386338752m_-945185604854300580quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D"m_-7301818504386338752m_-94518=
5604854300580elided-text">On 12 June 2017 at 15:12, Mathias Gaunard <span d=
ir=3D"ltr"><<a href=3D"mailto:mathias@gaunard.com" target=3D"_blank">mat=
hias@gaunard.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><span class=3D"m_-7301818504386338752m_-945185604854300580m_-1=
799384524084312081gmail-">On 12 June 2017 at 22:57, Nicol Bolas <span dir=
=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmcke=
sson@gmail.com</a>></span> wrote:<br></span><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><span class=3D"m_-730181850438633875=
2m_-945185604854300580m_-1799384524084312081gmail-"><br><br>On Monday, June=
12, 2017 at 3:57:23 PM UTC-4, Richard Smith wrote:</span><span><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><span class=3D"m_-7301818504386338752m_-945185604854300580m_-1=
799384524084312081gmail-">On 12 June 2017 at 10:22, <span dir=3D"ltr"><=
<a rel=3D"nofollow">matthias...@gmail.com</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br></div></bloc=
kquote></span><span class=3D"m_-7301818504386338752m_-945185604854300580m_-=
1799384524084312081gmail-"><div>I think it would be preferable to provide a=
range zip operation. Then adjacent_for_each(range, f) is for_each(zip(tail=
(range), range), f).</div></span></div></div></div></blockquote></span><spa=
n class=3D"m_-7301818504386338752m_-945185604854300580m_-179938452408431208=
1gmail-"><div><br>I have no idea what "for_each(zip(tail(range), range=
), f)" does. Also, if it does what I think it does, then you put `tail=
(range)` in the wrong place.<br></div></span></div></blockquote><div><br></=
div><div>I'd expect to get an error, since tail(range) and range are no=
t the same size.</div><div>I don't think it's sensible for zip to t=
ake the minimum size.</div></div></div></div></blockquote><div><br></div></=
div><div>You should take this up with Eric Niebler; his range-v3 library ta=
kes the smaller size:=C2=A0<a href=3D"https://github.com/ericniebler/range-=
v3/blob/master/include/range/v3/view/zip_with.hpp#L193" target=3D"_blank">h=
ttps://github.com/ericniebler/range-v3/blob/master/include/range/v3/view/zi=
p_with.hpp#L193</a> -- and it's not unreasonable to expect this to arri=
ve in the Ranges TS at some point.</div></div></div></div></blockquote></di=
v></div></div><div dir=3D"auto"><br></div></div><div dir=3D"auto"><div dir=
=3D"auto"><span style=3D"font-family:sans-serif">There are quite a few thin=
gs I don't like about range v3, I'm sure we'll have the opportu=
nity to bikeshed about it on the committee.</span><br></div></div><div dir=
=3D"auto"><div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></sp=
an></div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"m_-7301818504386338752m_-945185604854300580quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=
<br></div><div>(Python's zip also takes the length of the shortest sequ=
ence:=C2=A0<a href=3D"https://docs.python.org/3/library/functions.html#zip"=
target=3D"_blank">https://docs.python.org/3/library/functions.html#zip</a>=
)</div><div>(Haskell's zip=C2=A0also takes the length of the shortest s=
equence:=C2=A0<a href=3D"http://zvon.org/other/haskell/Outputprelude/zip_f.=
html" target=3D"_blank">http://zvon.org/other/haskell/Outputprelude/zip_f.h=
tml</a>)</div></div></div></div></blockquote></div></div></div><div dir=3D"=
auto"><br></div></div><div dir=3D"auto"><div dir=3D"auto">While that is goo=
d justification, I'm worried about silently dropping elements from a se=
quence.</div><div dir=3D"auto">It wouldn't be difficult to be explicit =
about removing the last element of the range, or concatenating the other ra=
nge with some dummy value.</div></div></blockquote><div><br></div><div>Do w=
e <i>really </i>need to do everything differently than all the other langua=
ges in the world, inventing dubious reasons to diverge? What exactly is you=
r goal? Is it to make it harder to migrate between languages by making faci=
lities with the exact same names behave slightly differently?</div><div><br=
></div><div>Similarly to explicitly dropping it, it wouldn't be hard to=
also have `zip_exact` or whatever to have the semantics that differ from o=
ther languages' `zip`.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya87%3DaW8rxfFTHLbk-YeL%3Dqpgzio=
CSLvE3z5c3jQ27GnNQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CALnjya87%3DaW8rxfFTHLbk-YeL%3DqpgzioCSLvE3z5c3jQ27GnNQ%40mail.gma=
il.com</a>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTo3gHxFz5iDSouvgOGNq02Mbs0wZyb=
m3HL4viLtLrRAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTo3gHxFz5i=
DSouvgOGNq02Mbs0wZybm3HL4viLtLrRAA%40mail.gmail.com</a>.<br />
--f403045f8d944ebb500551d3465d--
.
Author: Mathias Gaunard <mathias@gaunard.com>
Date: Tue, 13 Jun 2017 09:47:00 +0100
Raw View
--001a11450116a767cc0551d37a79
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 13 June 2017 at 09:32, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
>
>
> Do we *really *need to do everything differently than all the other
> languages in the world, inventing dubious reasons to diverge? What exactl=
y
> is your goal? Is it to make it harder to migrate between languages by
> making facilities with the exact same names behave slightly differently?
>
> Similarly to explicitly dropping it, it wouldn't be hard to also have
> `zip_exact` or whatever to have the semantics that differ from other
> languages' `zip`.
>
C++ tends to care more about little details.
Some languages throw exceptions in case of programmer error, C++ expects
the programmer to satisfy a given contract, and calling a function out of
contract is undefined behaviour.
Some languages use garbage collection so that the programmer does not have
to manage object life-time, C++ has sophisticated mechanisms to explicitly
manage object life-time.
Some languages don't care about extra overhead so long as it makes
productivity higher, C++ has a "don't pay for what you don't use" policy.
I could go on.
It is also fairly apparent that a zip iterator that does have this
guarantee is trivial and optimal, while one that does not must carry
additional state and do additional tests.
This is also consistent with algorithms like transform's two input
sequences variant, that does expect the two sequences to be the same size,
to the point that the end iterator of the second sequence isn't even
provided as it is redundant.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALnjya-6MAajQ9vpgsmNR8VxnqNR6pjALt%3D9Erjz-Noo8=
v5wDQ%40mail.gmail.com.
--001a11450116a767cc0551d37a79
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
3 June 2017 at 09:32, Micha=C5=82 Dominiak <span dir=3D"ltr"><<a href=3D=
"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>></s=
pan> wrote:<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"><div class=3D"gm=
ail_quote"><div><div class=3D"h5"><div><br></div></div></div><div>Do we <i>=
really </i>need to do everything differently than all the other languages i=
n the world, inventing dubious reasons to diverge? What exactly is your goa=
l? Is it to make it harder to migrate between languages by making facilitie=
s with the exact same names behave slightly differently?</div><div><br></di=
v><div>Similarly to explicitly dropping it, it wouldn't be hard to also=
have `zip_exact` or whatever to have the semantics that differ from other =
languages' `zip`.</div></div></div></blockquote><div><br></div><div>C++=
tends to care more about little details.<br>Some languages throw exception=
s in case of programmer error, C++ expects the programmer to satisfy a give=
n contract, and calling a function out of contract is undefined behaviour.<=
/div><div>Some languages use garbage collection so that the programmer does=
not have to manage object life-time, C++ has sophisticated mechanisms to e=
xplicitly manage object life-time.</div><div>Some languages don't care =
about extra overhead so long as it makes productivity higher, C++ has a &qu=
ot;don't pay for what you don't use" policy.</div><div>I could=
go on.<br></div><div><br></div><div>It is also fairly apparent that a zip =
iterator that does have this guarantee is trivial and optimal, while one th=
at does not must carry additional state and do additional tests.</div><div>=
This is also consistent with algorithms like transform's two input sequ=
ences variant, that does expect the two sequences to be the same size, to t=
he point that the end iterator of the second sequence isn't even provid=
ed as it is redundant.</div></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya-6MAajQ9vpgsmNR8VxnqNR6pjALt%3=
D9Erjz-Noo8v5wDQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-6MAajQ9=
vpgsmNR8VxnqNR6pjALt%3D9Erjz-Noo8v5wDQ%40mail.gmail.com</a>.<br />
--001a11450116a767cc0551d37a79--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Tue, 13 Jun 2017 08:50:07 +0000
Raw View
--94eb2c1cd564598b290551d38696
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 10:47 AM Mathias Gaunard <mathias@gaunard.com>
wrote:
> On 13 June 2017 at 09:32, Micha=C5=82 Dominiak <griwes@griwes.info> wrote=
:
>>
>>
>> Do we *really *need to do everything differently than all the other
>> languages in the world, inventing dubious reasons to diverge? What exact=
ly
>> is your goal? Is it to make it harder to migrate between languages by
>> making facilities with the exact same names behave slightly differently?
>>
>> Similarly to explicitly dropping it, it wouldn't be hard to also have
>> `zip_exact` or whatever to have the semantics that differ from other
>> languages' `zip`.
>>
>
> C++ tends to care more about little details.
> Some languages throw exceptions in case of programmer error, C++ expects
> the programmer to satisfy a given contract, and calling a function out of
> contract is undefined behaviour.
> Some languages use garbage collection so that the programmer does not hav=
e
> to manage object life-time, C++ has sophisticated mechanisms to explicitl=
y
> manage object life-time.
> Some languages don't care about extra overhead so long as it makes
> productivity higher, C++ has a "don't pay for what you don't use" policy.
> I could go on.
>
> It is also fairly apparent that a zip iterator that does have this
> guarantee is trivial and optimal, while one that does not must carry
> additional state and do additional tests.
> This is also consistent with algorithms like transform's two input
> sequences variant, that does expect the two sequences to be the same size=
,
> to the point that the end iterator of the second sequence isn't even
> provided as it is redundant.
>
Those standard algorithms doing that is one of my main sources of
enthusiasm for ranges, because with ranges I can just ignore the size
mismatches.
Also that requirement isn't exactly what you stated - the requirement is
that the second range is *at least* as long as the first. Which means that
they already picking the smallest sequence *in a way* - by forcing you to
manually do that.
> --
You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-6MAa=
jQ9vpgsmNR8VxnqNR6pjALt%3D9Erjz-Noo8v5wDQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-6MA=
ajQ9vpgsmNR8VxnqNR6pjALt%3D9Erjz-Noo8v5wDQ%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdTO9%3D0_1Wi1CfS1LL5UfFgoUaSFKx8%2BoXcEQy5=
FaXcgEw%40mail.gmail.com.
--94eb2c1cd564598b290551d38696
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Ju=
n 13, 2017 at 10:47 AM Mathias Gaunard <<a href=3D"mailto:mathias@gaunar=
d.com">mathias@gaunard.com</a>> wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e">On 13 June 2017 at 09:32, Micha=C5=82 Dominiak <span dir=3D"ltr"><<a =
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>=
></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_quote"><div><div class=3D"m_7064701716077366785h5"><div><br></di=
v></div></div><div>Do we <i>really </i>need to do everything differently th=
an all the other languages in the world, inventing dubious reasons to diver=
ge? What exactly is your goal? Is it to make it harder to migrate between l=
anguages by making facilities with the exact same names behave slightly dif=
ferently?</div><div><br></div><div>Similarly to explicitly dropping it, it =
wouldn't be hard to also have `zip_exact` or whatever to have the seman=
tics that differ from other languages' `zip`.</div></div></div></blockq=
uote><div><br></div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><div>C++ tends to care more about little =
details.<br>Some languages throw exceptions in case of programmer error, C+=
+ expects the programmer to satisfy a given contract, and calling a functio=
n out of contract is undefined behaviour.</div><div>Some languages use garb=
age collection so that the programmer does not have to manage object life-t=
ime, C++ has sophisticated mechanisms to explicitly manage object life-time=
..</div><div>Some languages don't care about extra overhead so long as i=
t makes productivity higher, C++ has a "don't pay for what you don=
't use" policy.</div><div>I could go on.<br></div><div><br></div><=
div>It is also fairly apparent that a zip iterator that does have this guar=
antee is trivial and optimal, while one that does not must carry additional=
state and do additional tests.</div><div>This is also consistent with algo=
rithms like transform's two input sequences variant, that does expect t=
he two sequences to be the same size, to the point that the end iterator of=
the second sequence isn't even provided as it is redundant.=C2=A0</div=
></div></div></div></blockquote><div><br></div><div>Those standard algorith=
ms doing that is one of my main sources of enthusiasm for ranges, because w=
ith ranges I can just ignore the size mismatches.</div><div><br></div><div>=
Also that requirement isn't exactly what you stated - the requirement i=
s that the second range is <b>at least</b>=C2=A0as long as the first. Which=
means that they already picking the smallest sequence <i>in a way</i>=C2=
=A0- by forcing you to manually do that.=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"></div></div>
<p></p>
-- =C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya-6MAajQ9vpgsmNR8VxnqNR6pjALt%3=
D9Erjz-Noo8v5wDQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALnjya-6MAajQ9vpgsmNR8VxnqNR6pjALt%3D9Erjz-Noo8v5wDQ%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTO9%3D0_1Wi1CfS1LL5UfFgoUaSFKx=
8%2BoXcEQy5FaXcgEw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTO9%3D=
0_1Wi1CfS1LL5UfFgoUaSFKx8%2BoXcEQy5FaXcgEw%40mail.gmail.com</a>.<br />
--94eb2c1cd564598b290551d38696--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Tue, 13 Jun 2017 08:50:50 +0000
Raw View
--001a11402612ec493d0551d38884
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 10:49 AM Micha=C5=82 Dominiak <griwes@griwes.info> =
wrote:
> On Tue, Jun 13, 2017 at 10:47 AM Mathias Gaunard <mathias@gaunard.com>
> wrote:
>
>> On 13 June 2017 at 09:32, Micha=C5=82 Dominiak <griwes@griwes.info> wrot=
e:
>>>
>>>
>>> Do we *really *need to do everything differently than all the other
>>> languages in the world, inventing dubious reasons to diverge? What exac=
tly
>>> is your goal? Is it to make it harder to migrate between languages by
>>> making facilities with the exact same names behave slightly differently=
?
>>>
>>> Similarly to explicitly dropping it, it wouldn't be hard to also have
>>> `zip_exact` or whatever to have the semantics that differ from other
>>> languages' `zip`.
>>>
>>
>> C++ tends to care more about little details.
>> Some languages throw exceptions in case of programmer error, C++ expects
>> the programmer to satisfy a given contract, and calling a function out o=
f
>> contract is undefined behaviour.
>> Some languages use garbage collection so that the programmer does not
>> have to manage object life-time, C++ has sophisticated mechanisms to
>> explicitly manage object life-time.
>> Some languages don't care about extra overhead so long as it makes
>> productivity higher, C++ has a "don't pay for what you don't use" policy=
..
>> I could go on.
>>
>> It is also fairly apparent that a zip iterator that does have this
>> guarantee is trivial and optimal, while one that does not must carry
>> additional state and do additional tests.
>> This is also consistent with algorithms like transform's two input
>> sequences variant, that does expect the two sequences to be the same siz=
e,
>> to the point that the end iterator of the second sequence isn't even
>> provided as it is redundant.
>>
>
> Those standard algorithms doing that is one of my main sources of
> enthusiasm for ranges, because with ranges I can just ignore the size
> mismatches.
>
Correction: with ranges I can easily write code (as in algorithms) that
just ignores the size mismatches.
>
> Also that requirement isn't exactly what you stated - the requirement is
> that the second range is *at least* as long as the first. Which means
> that they already picking the smallest sequence *in a way* - by forcing
> you to manually do that.
>
>> --
>
> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-6MA=
ajQ9vpgsmNR8VxnqNR6pjALt%3D9Erjz-Noo8v5wDQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-6M=
AajQ9vpgsmNR8VxnqNR6pjALt%3D9Erjz-Noo8v5wDQ%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdRJvBNn1gdgvkCU2sDbLAm5Ff3UWDFk6zwTzbP8TMn=
MuQ%40mail.gmail.com.
--001a11402612ec493d0551d38884
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Ju=
n 13, 2017 at 10:49 AM Micha=C5=82 Dominiak <<a href=3D"mailto:griwes@gr=
iwes.info">griwes@griwes.info</a>> wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On T=
ue, Jun 13, 2017 at 10:47 AM Mathias Gaunard <<a href=3D"mailto:mathias@=
gaunard.com" target=3D"_blank">mathias@gaunard.com</a>> wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">On 13 June 2017 at 09:32, Micha=C5=82 Dominiak <=
span dir=3D"ltr"><<a href=3D"mailto:griwes@griwes.info" target=3D"_blank=
">griwes@griwes.info</a>></span> wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div class=3D"gmail_quote"><div><div class=3D"m_-12737470230=
73244699m_7064701716077366785h5"><div><br></div></div></div><div>Do we <i>r=
eally </i>need to do everything differently than all the other languages in=
the world, inventing dubious reasons to diverge? What exactly is your goal=
? Is it to make it harder to migrate between languages by making facilities=
with the exact same names behave slightly differently?</div><div><br></div=
><div>Similarly to explicitly dropping it, it wouldn't be hard to also =
have `zip_exact` or whatever to have the semantics that differ from other l=
anguages' `zip`.</div></div></div></blockquote><div><br></div></div></d=
iv></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><div>C++ tends to care more about little details.<br>Some languages th=
row exceptions in case of programmer error, C++ expects the programmer to s=
atisfy a given contract, and calling a function out of contract is undefine=
d behaviour.</div><div>Some languages use garbage collection so that the pr=
ogrammer does not have to manage object life-time, C++ has sophisticated me=
chanisms to explicitly manage object life-time.</div><div>Some languages do=
n't care about extra overhead so long as it makes productivity higher, =
C++ has a "don't pay for what you don't use" policy.</div=
><div>I could go on.<br></div><div><br></div><div>It is also fairly apparen=
t that a zip iterator that does have this guarantee is trivial and optimal,=
while one that does not must carry additional state and do additional test=
s.</div><div>This is also consistent with algorithms like transform's t=
wo input sequences variant, that does expect the two sequences to be the sa=
me size, to the point that the end iterator of the second sequence isn'=
t even provided as it is redundant.=C2=A0</div></div></div></div></blockquo=
te><div><br></div></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><=
div>Those standard algorithms doing that is one of my main sources of enthu=
siasm for ranges, because with ranges I can just ignore the size mismatches=
..</div></div></div></blockquote><div><br></div><div>Correction: with ranges=
I can easily write code (as in algorithms) that just ignores the size mism=
atches.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_quote"><div><br></div><div>Also that requirement isn=
't exactly what you stated - the requirement is that the second range i=
s <b>at least</b>=C2=A0as long as the first. Which means that they already =
picking the smallest sequence <i>in a way</i>=C2=A0- by forcing you to manu=
ally do that.=C2=A0</div></div></div><div dir=3D"ltr"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"></div></div>
<p></p>
-- =C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya-6MAajQ9vpgsmNR8VxnqNR6pjALt%3=
D9Erjz-Noo8v5wDQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALnjya-6MAajQ9vpgsmNR8VxnqNR6pjALt%3D9Erjz-Noo8v5wDQ%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRJvBNn1gdgvkCU2sDbLAm5Ff3UWDFk=
6zwTzbP8TMnMuQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRJvBNn1gdg=
vkCU2sDbLAm5Ff3UWDFk6zwTzbP8TMnMuQ%40mail.gmail.com</a>.<br />
--001a11402612ec493d0551d38884--
.
Author: Mathias Gaunard <mathias@gaunard.com>
Date: Tue, 13 Jun 2017 09:59:17 +0100
Raw View
--94eb2c0541b890aa370551d3a67d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 13 June 2017 at 09:50, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
>
> Also that requirement isn't exactly what you stated - the requirement is
> that the second range is *at least* as long as the first. Which means
> that they already picking the smallest sequence *in a way* - by forcing
> you to manually do that.
>
That's not my understanding from the ambiguous "specification" of the
python and haskell zips.
It's also not what range v3 does from a look at the implementation (minimum
with special code for unit and infinite sequences).
I don't think it's a good idea to make that sort of thing sensitive to
argument order anyway.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALnjya-3jyDRzAPFJhqQYhTmvb6QLX2WE3oH6ToOzCc2JcX=
Qig%40mail.gmail.com.
--94eb2c0541b890aa370551d3a67d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
3 June 2017 at 09:50, Micha=C5=82 Dominiak <span dir=3D"ltr"><<a href=3D=
"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>></s=
pan> 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"><div class=
=3D"gmail_quote"><div><br></div><div>Also that requirement isn't exactl=
y what you stated - the requirement is that the second range is <b>at least=
</b>=C2=A0as long as the first. Which means that they already picking the s=
mallest sequence <i>in a way</i>=C2=A0- by forcing you to manually do that.=
=C2=A0</div></div></div></blockquote><div><br></div><div>That's not my =
understanding from the ambiguous "specification" of the python an=
d haskell zips.<br>It's also not what range v3 does from a look at the =
implementation (minimum with special code for unit and infinite sequences).=
</div><div><br></div><div>I don't think it's a good idea to make th=
at sort of thing sensitive to argument order anyway.</div></div></div></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya-3jyDRzAPFJhqQYhTmvb6QLX2WE3oH=
6ToOzCc2JcXQig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-3jyDRzAPF=
JhqQYhTmvb6QLX2WE3oH6ToOzCc2JcXQig%40mail.gmail.com</a>.<br />
--94eb2c0541b890aa370551d3a67d--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 13 Jun 2017 09:39:01 -0700
Raw View
On Tue, Jun 13, 2017 at 1:47 AM, Mathias Gaunard <mathias@gaunard.com> wrot=
e:
> On 13 June 2017 at 09:32, Micha=C5=82 Dominiak <griwes@griwes.info> wrote=
:
>>
>>
>> Do we really need to do everything differently than all the other
>> languages in the world, inventing dubious reasons to diverge? What exact=
ly
>> is your goal? Is it to make it harder to migrate between languages by ma=
king
>> facilities with the exact same names behave slightly differently?
>>
>> Similarly to explicitly dropping it, it wouldn't be hard to also have
>> `zip_exact` or whatever to have the semantics that differ from other
>> languages' `zip`.
>
>
> C++ tends to care more about little details.
> Some languages throw exceptions in case of programmer error, C++ expects =
the
> programmer to satisfy a given contract, and calling a function out of
> contract is undefined behaviour.
> Some languages use garbage collection so that the programmer does not hav=
e
> to manage object life-time, C++ has sophisticated mechanisms to explicitl=
y
> manage object life-time.
> Some languages don't care about extra overhead so long as it makes
> productivity higher, C++ has a "don't pay for what you don't use" policy.
> I could go on.
>
> It is also fairly apparent that a zip iterator that does have this guaran=
tee
> is trivial and optimal, while one that does not must carry additional sta=
te
> and do additional tests.
> This is also consistent with algorithms like transform's two input sequen=
ces
> variant, that does expect the two sequences to be the same size, to the
> point that the end iterator of the second sequence isn't even provided as=
it
> is redundant.
This causes enough bugs, including security bugs, that we added a
version that takes both end iterators for some of the algorithms, like
http://en.cppreference.com/w/cpp/algorithm/equal. We didn't do it
uniformly across the standard library, unfortunately. I'd like to
avoid making the same mistake for zip().
Jeffrey
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANh-dX%3D%3DNa8O8fbZ7gFrn-bCcgHd-78wmyrDV_sUTMy=
NV9dK0Q%40mail.gmail.com.
.
Author: Mathias Gaunard <mathias@gaunard.com>
Date: Tue, 13 Jun 2017 19:21:54 +0100
Raw View
--94eb2c19e324a78dd80551db82f4
Content-Type: text/plain; charset="UTF-8"
On 13 June 2017 at 17:39, 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>
> This causes enough bugs, including security bugs, that we added a
> version that takes both end iterators for some of the algorithms, like
> http://en.cppreference.com/w/cpp/algorithm/equal. We didn't do it
> uniformly across the standard library, unfortunately. I'd like to
> avoid making the same mistake for zip().
equal can be extended to have meaning for sequences of different sizes
fairly naturally, and the overload is a convenience since the other one is
still available and not deprecated in any way.
In any case, some developers introducing bugs because they're not
satisfying narrow contracts is not good justification to replace those
contracts by wide ones.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya8uTv%2Bz1%2B5u96ufbh-NSHNvE9x0mjZtRxXM4zLHTXjbpg%40mail.gmail.com.
--94eb2c19e324a78dd80551db82f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
3 June 2017 at 17:39, 'Jeffrey Yasskin' via ISO C++ Standard - Futu=
re Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.o=
rg" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"gmail-HOEnZb">=
<div class=3D"gmail-h5"><br>
</div></div>This causes enough bugs, including security bugs, that we added=
a<br>
version that takes both end iterators for some of the algorithms, like<br>
<a href=3D"http://en.cppreference.com/w/cpp/algorithm/equal" rel=3D"norefer=
rer" target=3D"_blank">http://en.cppreference.com/w/<wbr>cpp/algorithm/equa=
l</a>. We didn't do it<br>
uniformly across the standard library, unfortunately. I'd like to<br>
avoid making the same mistake for zip().</blockquote><div><br></div><div>eq=
ual can be extended to have meaning for sequences of different sizes fairly=
naturally, and the overload is a convenience since the other one is still =
available and not deprecated in any way.<br></div><div><br></div><div>In an=
y case, some developers introducing bugs because they're not satisfying=
narrow contracts is not good justification to replace those contracts by w=
ide ones.<br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya8uTv%2Bz1%2B5u96ufbh-NSHNvE9x0=
mjZtRxXM4zLHTXjbpg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya8uTv%2=
Bz1%2B5u96ufbh-NSHNvE9x0mjZtRxXM4zLHTXjbpg%40mail.gmail.com</a>.<br />
--94eb2c19e324a78dd80551db82f4--
.
Author: matthias.s.fuchs@gmail.com
Date: Thu, 15 Jun 2017 07:50:57 -0700 (PDT)
Raw View
------=_Part_474_431693312.1497538257790
Content-Type: multipart/alternative;
boundary="----=_Part_475_631320610.1497538257790"
------=_Part_475_631320610.1497538257790
Content-Type: text/plain; charset="UTF-8"
Thank you for all responses and the interesting discussion.
Unfortunately I had no time to respond earlier.
While I like the range proposal I want to keep this suggestion separate
from it.
What is to become STL 2 is not completely certain yet.
I also think that we will live with the STL 1 for quite a while, even with
a STL 2 approaching.
As a result in my opinion we should continue to add usable algorithms [1]
to STL 1 in the foreseeable future.
As Matthias Gaunard pointed out the STL 1 lacks much flexibility
adjacent_for_each won't change that.
Maybe the STL 2 will fix that, I don't know.
So far there are some algorithms that work on adjacent elements:
* adjacent_find
* adjacent_difference
* sorting algorithms
* ...?
I think that adjacent_for_each is missing in that list.
The main usage I had in mind is iterating over a sequence of continuous
items n, where each element i is the start point of something, while its
following item i+1 is the end point.
This can be used in polylines stored as sequence of points, in sequences of
dates (e.g. start date of presidencies), etc.
adjacent_for_each would allow iterating over a list of connected vertices
as if it was a list of edges (for a polyline).
Instead of storing the edges just the vertices need to be stored. This
saves roughly half the memory, while still working naturally with the data.
Best,
Matthias
[1] We are here to find out if adjacent_for_each can fit that bill :)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fe740a99-033e-444a-a788-76afbe940c0f%40isocpp.org.
------=_Part_475_631320610.1497538257790
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Thank you for all responses and the interesting discu=
ssion.</div><div>Unfortunately I had no time to respond earlier.</div><div>=
<br></div><div>While I like the range proposal I want to keep this suggesti=
on separate from it.</div><div>What is to become STL 2 is not completely ce=
rtain yet.</div><div>I also think that we will live with the STL 1 for quit=
e a while, even with a STL 2 approaching.</div><div>As a result in my opini=
on we should continue to add usable algorithms [1] to STL 1 in the foreseea=
ble future.</div><div><br></div><div>As Matthias Gaunard pointed out the ST=
L 1 lacks much flexibility</div><div>adjacent_for_each won't change tha=
t.</div><div>Maybe the STL 2 will fix that, I don't know.</div><div><br=
></div><div>So far there are some algorithms that work on adjacent elements=
:</div><div>* adjacent_find</div><div>* adjacent_difference</div><div>* sor=
ting algorithms</div><div>* ...?</div><div><br></div><div>I think that adja=
cent_for_each is missing in that list.</div><div><br></div><div>The main us=
age I had in mind is iterating over a sequence of continuous items n, where=
each element i is the start point of something, while its following item i=
+1 is the end point.</div><div>This can be used in polylines stored as sequ=
ence of points, in sequences of dates (e.g. start date of presidencies), et=
c.</div><div><br></div><div>adjacent_for_each would allow iterating over a =
list of connected vertices as if it was a list of edges (for a polyline).</=
div><div>Instead of storing the edges just the vertices need to be stored. =
This saves roughly half the memory, while still working naturally with the =
data.</div><div><br></div><div>Best,</div><div>Matthias</div><div><br></div=
><div>[1] We are here to find out if adjacent_for_each can fit that bill :)=
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fe740a99-033e-444a-a788-76afbe940c0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fe740a99-033e-444a-a788-76afbe940c0f=
%40isocpp.org</a>.<br />
------=_Part_475_631320610.1497538257790--
------=_Part_474_431693312.1497538257790--
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Tue, 20 Jun 2017 23:33:52 +0200
Raw View
On 2017-06-13 07:12, Akira Takahashi wrote:
> Hi,
>
> 2017-06-13 2:22 GMT+09:00 <matthias.s.fuchs@gmail.com>:
>
>> Hi,
>>
>> std::adjacent_for_each would apply the given function object to
>> adjacent elements of the sequence.
>> The implementation would be something like:
>
> FYI, my `adjacent_for_each()` implementation is here (range version):
> https://gist.github.com/faithandbrave/370155a2078b158853b3 [1]
Bugreport: You call the argument InputRange, but you require forward
iterators, because you advance 'first' twice. Input Iterators are
single-traversal. :)
For a non-range-based approach ("STL 1"-compatible) that also uses the
correct name (yes, adjacent_find should have been called find_adjacent),
see
https://github.com/marc-kdab/aastl/blob/0e35d6da1adec8f5c67d9b910c23081c795c451b/include/aastl/for_each.hpp
Thanks,
Marc
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/50d3618be8a9c2a0f4d600ec24df9d3e%40kdab.com.
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Tue, 20 Jun 2017 23:44:51 +0200
Raw View
On 2017-06-20 23:33, Marc Mutz wrote:
[...]
> For a non-range-based approach ("STL 1"-compatible) that also uses the
> correct name (yes, adjacent_find should have been called
> find_adjacent), see
> https://github.com/marc-kdab/aastl/blob/0e35d6da1adec8f5c67d9b910c23081c795c451b/include/aastl/for_each.hpp
[...]
See also https://github.com/marc-kdab/aastl/issues/7 for naming.
Thanks,
Marc
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/25730124d28074d45165b54c4c785ad9%40kdab.com.
.
Author: Akira Takahashi <faithandbrave@gmail.com>
Date: Wed, 21 Jun 2017 13:09:46 +0900
Raw View
--001a11497fe2f09046055270891d
Content-Type: text/plain; charset="UTF-8"
2017-06-21 6:33 GMT+09:00 Marc Mutz <marc.mutz@kdab.com>:
> On 2017-06-13 07:12, Akira Takahashi wrote:
>
>>
>> FYI, my `adjacent_for_each()` implementation is here (range version):
>> https://gist.github.com/faithandbrave/370155a2078b158853b3 [1]
>>
>
> Bugreport: You call the argument InputRange, but you require forward
> iterators, because you advance 'first' twice. Input Iterators are
> single-traversal. :)
>
"twice" means `++first` and `std::next(first)` ?
`std::next()` copy iterator object. single-traversal requires copied
iterator?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAED3xEiTVbEXZF7tkyiAxFWW7NuBwAdQU0d7GpEh-N_kTCkyBQ%40mail.gmail.com.
--001a11497fe2f09046055270891d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2017-06-21 6:33 GMT+09:00 Marc Mutz <span dir=3D"ltr"><<a href=3D"mailto=
:marc.mutz@kdab.com" target=3D"_blank">marc.mutz@kdab.com</a>></span>:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On=
2017-06-13 07:12, Akira Takahashi wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><br>
=C2=A0FYI, my `adjacent_for_each()` implementation is here (range version):=
<br>
</div></div><a href=3D"https://gist.github.com/faithandbrave/370155a2078b15=
8853b3" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/faitha=
<wbr>ndbrave/370155a2078b158853b3</a> [1]<br>
</blockquote>
<br>
Bugreport: You call the argument InputRange, but you require forward iterat=
ors, because you advance 'first' twice. Input Iterators are single-=
traversal. :)<br></blockquote><div><br></div><div>=C2=A0"twice" m=
eans `++first` and `std::next(first)` ?</div><div>`std::next()` copy iterat=
or object. single-traversal requires copied iterator?</div></div></div></di=
v>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAED3xEiTVbEXZF7tkyiAxFWW7NuBwAdQU0d7=
GpEh-N_kTCkyBQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAED3xEiTVbEXZF7t=
kyiAxFWW7NuBwAdQU0d7GpEh-N_kTCkyBQ%40mail.gmail.com</a>.<br />
--001a11497fe2f09046055270891d--
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Wed, 21 Jun 2017 10:36:16 +0200
Raw View
On Wednesday 21 June 2017 06:09:46 Akira Takahashi wrote:
> 2017-06-21 6:33 GMT+09:00 Marc Mutz <marc.mutz@kdab.com>:
> > On 2017-06-13 07:12, Akira Takahashi wrote:
> >> FYI, my `adjacent_for_each()` implementation is here (range version):
> >> https://gist.github.com/faithandbrave/370155a2078b158853b3 [1]
> >
> > Bugreport: You call the argument InputRange, but you require forward
> > iterators, because you advance 'first' twice. Input Iterators are
> > single-traversal. :)
>
> "twice" means `++first` and `std::next(first)` ?
Correct.
> `std::next()` copy iterator object. single-traversal requires copied
> iterator?
Does not matter whether you deref the iterator or not. You cannot traverse
[first, 1) twice: http://en.cppreference.com/w/cpp/concept/InputIterator,
first paragraph.
Thanks,
Marc
--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
.
Author: Akira Takahashi <faithandbrave@gmail.com>
Date: Wed, 21 Jun 2017 18:38:09 +0900
Raw View
--001a1145b98652df0d05527520b7
Content-Type: text/plain; charset="UTF-8"
2017-06-21 17:36 GMT+09:00 Marc Mutz <marc.mutz@kdab.com>:
> On Wednesday 21 June 2017 06:09:46 Akira Takahashi wrote:
>
> > `std::next()` copy iterator object. single-traversal requires copied
> > iterator?
>
> Does not matter whether you deref the iterator or not. You cannot traverse
> [first, 1) twice: http://en.cppreference.com/w/cpp/concept/InputIterator,
> first paragraph.
>
Ah, I understand.
Thanks Marc. I wrote known issue to the gist.
Thanks,
Akira
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAED3xEhskrq%3Dr-N4h8D%3DSOEtHwR1iUz2tX1pxJMUFaeyMAnbEA%40mail.gmail.com.
--001a1145b98652df0d05527520b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-06-21 17:36 GMT+09:00 Marc Mutz <span dir=3D"ltr"><<a href=3D"mailto:ma=
rc.mutz@kdab.com" target=3D"_blank">marc.mutz@kdab.com</a>></span>:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><span class=3D"">On Wednesday 21 June 2017 06=
:09:46 Akira Takahashi wrote:<br></span><span class=3D""><br>
> `std::next()` copy iterator object. single-traversal requires copied<b=
r>
> iterator?<br>
<br>
</span>Does not matter whether you deref the iterator or not. You cannot tr=
averse<br>
[first, 1) twice: <a href=3D"http://en.cppreference.com/w/cpp/concept/Input=
Iterator" rel=3D"noreferrer" target=3D"_blank">http://en.cppreference.com/w=
/<wbr>cpp/concept/InputIterator</a>,<br>
first paragraph.<br></blockquote><div><br></div><div>Ah, I understand.</div=
><div>Thanks Marc. I wrote known issue to the gist.</div><div><br></div><di=
v>Thanks,</div><div>Akira</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAED3xEhskrq%3Dr-N4h8D%3DSOEtHwR1iUz2=
tX1pxJMUFaeyMAnbEA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAED3xEhskrq%=
3Dr-N4h8D%3DSOEtHwR1iUz2tX1pxJMUFaeyMAnbEA%40mail.gmail.com</a>.<br />
--001a1145b98652df0d05527520b7--
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Fri, 23 Jun 2017 11:11:42 +0200
Raw View
On 2017-06-13 00:12, Richard Smith wrote:
[...]
> So I'd generally favour adding primitive algorithms from which other
> algorithms can be constructed.
[...]
template <typename InputIterator, typename OutputIterator, typename
Joiner>
OutputIterator join(InputIterator first, InputIterator last,
OutputIterator dest, const Joiner &joiner) {
if (first != last) {
*dest = *first;
++dest;
}
for_each_adjacent_pair(first, last, [&dest, &joiner](auto &, auto
&second) {
*dest = joiner;
++dest;
*dest = second;
++dest;
});
return dest;
}
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2c08885b641c44171749bd6f852a2916%40kdab.com.
.
Author: Marc Mutz <marc.mutz@kdab.com>
Date: Fri, 23 Jun 2017 11:23:51 +0200
Raw View
On 2017-06-13 00:12, Richard Smith wrote:
[...]
> uncommon algorithms such as [for_each_adjacent_pair]
[...]
https://github.com/KDE/kleopatra/blob/master/src/newcertificatewizard/newcertificatewizard.cpp#L120
This algorithm was (probably independently; can only talk about myself
here) discovered by at least Sean Parent (IIRC), Marshal Clow, and me.
Probably many more developers who don't give talks on CppCon and hang
around here.
I'm all for including it.
Thanks,
Marc
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4520083addf160b4353c76cfd0f5a9ec%40kdab.com.
.