------=_Part_185_3125088.1385070943502
Content-Type: text/plain; charset=ISO-8859-1

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); });

2. The problem of ABR/VLA and standard algorithm.
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/.

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

<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>&nbsp; for(const auto&amp; v,=
 cont)&nbsp; f(a);<br>in the a code that uses a STL-like algorithm, for exa=
mple the parallel version of the for. The recommended syntax (at least from=
 presentation<br>I have seen about C++11) is:<br>&nbsp; parallel_for(std::b=
egin(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 solution =
will be to use:<br>&nbsp; parallel_for(begin(cont), end(cont), [] (const au=
to&amp; a) { f(a); });<br>This will work for the standard container and oth=
er containers that defines begin, end function to be found by ADL (and I th=
ink it is a good practise to<br>define such functions), but will not work f=
or build-in arraysl<br><br>The final option that work in are of the cases t=
hat for-each works is to write code as:<br>&nbsp; using std::begin; using s=
td::end;<br>&nbsp; parallel_for(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>&=
nbsp; template&lt;typename C&gt;<br>&nbsp; inline delctype(auto) front(C&am=
p;&amp; c) nexcept(noexcept(*begin(c))) //how to add using&nbsp; std::begin=
 here?<br>&nbsp; {<br>&nbsp;&nbsp;&nbsp; return *begin(c);<br>&nbsp; <br>&n=
bsp; }<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 f=
or build-in arrays would be a build-in function, then we would be able to s=
imply use:<br>&nbsp; parallel_for(begin(cont), end(cont), [] (const auto&am=
p; a) { f(a); });<br><br>2. The problem of ABR/VLA and standard algorithm.<=
br>The proposed arrays of runtime bound will work with the for-each syntax,=
 so the code will work:<br>&nbsp; int n =3D g();<br>&nbsp; int arb[n];<br>&=
nbsp; for(const auto&amp; v, arb)&nbsp; 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>&nbsp; parallel_for(arb, arb+n, [] (const auto&amp; a) { =
f(a); });<br>insetead of:<br>&nbsp; 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 require special compiler support to work (as for-each and lambd=
a capture) and this for me is another argument make this<br>functions build=
-in.<br><br>Also in same context, the size of the array of runtime bound is=
 know only for the compiler. For example:<br>&nbsp; int n =3D g();<br>&nbsp=
; int arb[n];<br>&nbsp; [&amp;arb]() {&nbsp; //This code will work accordin=
g to the library TS.<br>&nbsp;&nbsp;&nbsp; for(const auto&amp; v, arb)&nbsp=
; f(a); //The size is silent captured by compiler <br>&nbsp; };<br>While th=
e similiar code:<br>&nbsp; &nbsp; int n =3D g();<br>&nbsp; int arb[n];<br>&=
nbsp; [&amp;arb]() {&nbsp; //This code will work according to the library T=
S.<br>&nbsp;&nbsp;&nbsp; &nbsp; parallel_for(arb, arb+n, [] (const auto&amp=
; a) { f(a); }); //this want work as n is not captured explicitly<br>&nbsp;=
 };<br><br>3. In conclusion, I thin that we need additiona overloads for be=
gin and end for ARB with the special support from the compiler. If <br>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,<br>for the us=
er convenience.<br></div>

<p></p>

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

------=_Part_185_3125088.1385070943502--

.