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

On Thu, Nov 21, 2013 at 1:55 PM, <tomaszkam@gmail.com> wrote:

> Hi,
>
> I would like to present (for a discussion) idea of moving the begin, end
> overloads for build-in arrays to be build in in the language.
>
> 1. Using the standard algorithms with any container
> As a first motivation example I would like to discuss the problem of
> changing the code that uses the for-each syntax:
>   for(const auto& v, cont)  f(a);
> in the a code that uses a STL-like algorithm, for example the parallel
> version of the for. The recommended syntax (at least from presentation
> I have seen about C++11) is:
>   parallel_for(std::begin(cont), std::end(cont), [] (const auto& a) {
> f(a); });
> This code will work for build-in arrays, container for STL and other that
> has .begin(), .end() function, but will not work with the container or
> ranges
> that defines free standing begin(C), end(C) in their name space to be
> found via ADL, while the C++11 will work for all of them.
>
> The other solution will be to use:
>   parallel_for(begin(cont), end(cont), [] (const auto& a) { f(a); });
> This will work for the standard container and other containers that
> defines begin, end function to be found by ADL (and I think it is a good
> practise to
> define such functions), but will not work for build-in arraysl
>
> The final option that work in are of the cases that for-each works is to
> write code as:
>   using std::begin; using std::end;
>   parallel_for(begin(cont), end(cont), [] (const auto& a) { f(a); });
> This work will work fine until we will want to use it in the combination
> with the no except for the functions,
> for example:
>   template<typename C>
>   inline delctype(auto) front(C&& c) nexcept(noexcept(*begin(c))) //how to
> add using  std::begin here?
>   {
>     return *begin(c);
>
>   }
> Which leads us to the same problem as for swap functions, that is proposed
> to be solved by adding is_nothrow_swapable.
>
> If the begin for build-in arrays would be a build-in function, then we
> would be able to simply use:
>   parallel_for(begin(cont), end(cont), [] (const auto& a) { f(a); });
>

See range_begin and range_end in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3763.html --
indeed, this entire problem space is better addressed by the approach of
N3763. For your example

  for (const auto &a : cont) f(a);

would be rewritten this way to use parallel_for:

  parallel_for(cont, [] (const auto &a) { f(a); });

So this seems to be a non-issue assuming we get ranges in C++17.

2. The problem of ABR/VLA and standard algorithm.
>

C++14 does not have ARBs; do you intend to target this change at the array
extensions TS or at the standard? It seems like this is only a corner of
the real problem here: that ARBs do not act as first-class types. But
that's OK: people can trivially change their code to use std::dynarray
instead of an ARB.

The proposed arrays of runtime bound will work with the for-each syntax, so
> the code will work:
>   int n = g();
>   int arb[n];
>   for(const auto& v, arb)  f(a);
> But if the user would like to exchange it to other algorithm, as in our
> previous, then the code must be written as:
>   parallel_for(arb, arb+n, [] (const auto& a) { f(a); });
> insetead of:
>   parallel_for(begin(arb), end(arb), [] (const auto& a) { f(a); });
> Which add another case in the language. I know that this is designed that
> way because of the begin/end function for ARB
> will require special compiler support to work (as for-each and lambda
> capture) and this for me is another argument make this
> functions build-in.
>
> Also in same context, the size of the array of runtime bound is know only
> for the compiler. For example:
>   int n = g();
>   int arb[n];
>   [&arb]() {  //This code will work according to the library TS.
>     for(const auto& v, arb)  f(a); //The size is silent captured by
> compiler
>   };
> While the similiar code:
>     int n = g();
>   int arb[n];
>   [&arb]() {  //This code will work according to the library TS.
>       parallel_for(arb, arb+n, [] (const auto& a) { f(a); }); //this want
> work as n is not captured explicitly
>   };
>
> 3. In conclusion, I thin that we need additiona overloads for begin and
> end for ARB with the special support from the compiler. If
> the compiler decides so, they may be placed to in std name space.
> Furthermore I would suggest to make this overloads as build in candidates,
> for the user convenience.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">On Thu, Nov 21, 2013 at 1:55 PM,  <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:tomaszkam@gmail.com" target=3D"_blank">tomaszkam@gmail.com<=
/a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">
<div dir=3D"ltr">Hi,<br><br>I would like to present (for a discussion) idea=
 of moving the begin, end overloads for build-in arrays to be build in in t=
he language.<br><br>1. Using the standard algorithms with any container<br>
As a first motivation example I would like to discuss the problem of changi=
ng the code that uses the for-each syntax:<br>=A0 for(const auto&amp; v, co=
nt)=A0 f(a);<br>in the a code that uses a STL-like algorithm, for example t=
he parallel version of the for. The recommended syntax (at least from prese=
ntation<br>
I have seen about C++11) is:<br>=A0 parallel_for(std::begin(cont), std::end=
(cont), [] (const auto&amp; a) { f(a); });<br>This code will work for build=
-in arrays, container for STL and other that has .begin(), .end() function,=
 but will not work with the container or ranges<br>
that defines free standing begin(C), end(C) in their name space to be found=
 via ADL, while the C++11 will work for all of them.<br><br>The other solut=
ion will be to use:<br>=A0 parallel_for(begin(cont), end(cont), [] (const a=
uto&amp; a) { f(a); });<br>
This will work for the standard container and other containers that defines=
 begin, end function to be found by ADL (and I think it is a good practise =
to<br>define such functions), but will not work for build-in arraysl<br>
<br>The final option that work in are of the cases that for-each works is t=
o write code as:<br>=A0 using std::begin; using std::end;<br>=A0 parallel_f=
or(begin(cont), end(cont), [] (const auto&amp; a) { f(a); });<br>This work =
will work fine until we will want to use it in the combination with the no =
except for the functions,<br>
for example:<br>=A0 template&lt;typename C&gt;<br>=A0 inline delctype(auto)=
 front(C&amp;&amp; c) nexcept(noexcept(*begin(c))) //how to add using=A0 st=
d::begin here?<br>=A0 {<br>=A0=A0=A0 return *begin(c);<br>=A0 <br>=A0 }<br>=
Which leads us to the same problem as for swap functions, that is proposed =
to be solved by adding is_nothrow_swapable.<br>
<br>If the begin for build-in arrays would be a build-in function, then we =
would be able to simply use:<br>=A0 parallel_for(begin(cont), end(cont), []=
 (const auto&amp; a) { f(a); });<br></div></blockquote><div><br></div><div>
See range_begin and range_end in=A0<a href=3D"http://www.open-std.org/jtc1/=
sc22/wg21/docs/papers/2013/n3763.html">http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2013/n3763.html</a> -- indeed, this entire problem space is =
better addressed by the approach of N3763. For your example</div>
<div><br></div><div>=A0 for (const auto &amp;a : cont) f(a);</div><div><br>=
</div><div>would be rewritten this way to use parallel_for:</div><div><br><=
/div><div>=A0 parallel_for(cont, [] (const auto &amp;a) { f(a); });</div><d=
iv>
<br></div><div>So this seems to be a non-issue assuming we get ranges in C+=
+17.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr">2. The problem of ABR/VLA and standard algorithm.<br></div=
></blockquote><div><br></div><div>C++14 does not have ARBs; do you intend t=
o target this change at the array extensions TS or at the standard? It seem=
s like this is only a corner of the real problem here: that ARBs do not act=
 as first-class types. But that&#39;s OK: people can trivially change their=
 code to use std::dynarray instead of an ARB.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr">The proposed arrays of run=
time bound will work with the for-each syntax, so the code will work:<br>
=A0 int n =3D g();<br>=A0 int arb[n];<br>=A0 for(const auto&amp; v, arb)=A0=
 f(a);<br>But if the user would like to exchange it to other algorithm, as =
in our previous, then the code must be written as:<br>=A0 parallel_for(arb,=
 arb+n, [] (const auto&amp; a) { f(a); });<br>
insetead of:<br>=A0 parallel_for(begin(arb), end(arb), [] (const auto&amp; =
a) { f(a); });<br>Which add another case in the language. I know that this =
is designed that way because of the begin/end function for ARB<br>will requ=
ire special compiler support to work (as for-each and lambda capture) and t=
his for me is another argument make this<br>
functions build-in.<br><br>Also in same context, the size of the array of r=
untime bound is know only for the compiler. For example:<br>=A0 int n =3D g=
();<br>=A0 int arb[n];<br>=A0 [&amp;arb]() {=A0 //This code will work accor=
ding to the library TS.<br>
=A0=A0=A0 for(const auto&amp; v, arb)=A0 f(a); //The size is silent capture=
d by compiler <br>=A0 };<br>While the similiar code:<br>=A0 =A0 int n =3D g=
();<br>=A0 int arb[n];<br>=A0 [&amp;arb]() {=A0 //This code will work accor=
ding to the library TS.<br>
=A0=A0=A0 =A0 parallel_for(arb, arb+n, [] (const auto&amp; a) { f(a); }); /=
/this want work as n is not captured explicitly<br>=A0 };<br><br>3. In conc=
lusion, I thin that we need additiona overloads for begin and end for ARB w=
ith the special support from the compiler. If <br>
the compiler decides so, they may be placed to in std name space. Furthermo=
re I would suggest to make this overloads as build in candidates,<br>for th=
e user convenience.<span class=3D""><font color=3D"#888888"><br></font></sp=
an></div>
<span class=3D""><font color=3D"#888888">

<p></p>

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

<p></p>

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

--001a1133225297976804ebb8041d--

.