Topic: Static Iteration proposal (modelled after static
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 11 Nov 2012 13:06:26 -0800 (PST)
Raw View
------=_Part_39_23926584.1352667986154
Content-Type: text/plain; charset=ISO-8859-1
More justifications:
There is currently a proposal to expand constexpr functions to be able to
be more than just a returned expression<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3444.html>.
It does not allow any looping constructs, but it does allow for conditional
if. `static for` would be a good match for it, allowing constexpr looping
over constant expressions.
I don't think the proposal needs to allow for more arbitrary looping
constructs like `static while` and `static do/while`. The implementation
burden in such cases seems, from a lay-perspective, somewhat scary. Even
range-based for is a problem, because it's based on `std::begin/std::end`,
which are not `constexpr`. And everything that feeds the loop in `static
for` needs to be a `constexpr`.
What would be a good proof-of-concept that `static` can work with `while`,
`do/while`, and range-based `for` would be to write some loops in that and
show *exactly *what the equivalent C++ code for it would be. If it can be
done algorithmically, then it should be fine in terms of implementation.
On Sunday, November 11, 2012 12:31:01 PM UTC-8, Clayto...@gmail.com wrote:
>
> Hi All,
>
> I'd like to make a proposal that is complementary to N3329 (static if;
> available at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf), which
> is currently under consideration. I believe there is a strong case to be
> made that static iteration loops would fit nicely alongside static if. A
> draft proposal is attached (Static Loops.pdf). In brief, though, the goal
> is to provide an alternative to template recursion that more closely models
> the runtime language, but forces loop unrolling during translation. For
> example, the following function would do something like boost.fusion's
> for_each:
>
> template<typename F, typename ... Types>
> void for_each(tuple<Types...> Tuple, F f)
> {
> static for(size_t i = 0; i < sizeof...(Types); i++) {
> f(get<i>(Tuple));
> }
> }
>
> The "static for" tells the compiler to unroll the for loop during
> translation. Then, get<i> can be instantiated separately for each
> iteration. The challenge to the proposal, which I've tried to address, is
> detecting when a loop can be unrolled in this fashion.
>
> I would be grateful for people's comments!
>
> Thanks,
> Clayton
>
--
------=_Part_39_23926584.1352667986154
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
More justifications:<br><br>There is currently a <a href=3D"http://www.open=
-std.org/JTC1/SC22/WG21/docs/papers/2012/n3444.html">proposal to expand con=
stexpr functions to be able to be more than just a returned expression</a>.=
It does not allow any looping constructs, but it does allow for conditiona=
l if. `static for` would be a good match for it, allowing constexpr looping=
over constant expressions.<br><br>I don't think the proposal needs to allo=
w for more arbitrary looping constructs like `static while` and `static do/=
while`. The implementation burden in such cases seems, from a lay-perspecti=
ve, somewhat scary. Even range-based for is a problem, because it's based o=
n `std::begin/std::end`, which are not `constexpr`. And everything that fee=
ds the loop in `static for` needs to be a `constexpr`.<br><br>What would be=
a good proof-of-concept that `static` can work with `while`, `do/while`, a=
nd range-based `for` would be to write some loops in that and show <i>exact=
ly </i>what the equivalent C++ code for it would be. If it can be done algo=
rithmically, then it should be fine in terms of implementation.<br><br>On S=
unday, November 11, 2012 12:31:01 PM UTC-8, Clayto...@gmail.com wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">Hi All,<br><br>I'd like to make a p=
roposal that is complementary to N3329 (static if; available at <a href=3D"=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf" target=
=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2012/<w=
br>n3329.pdf</a>), which is currently under consideration. I believe =
there is a strong case to be made that static iteration loops would fit nic=
ely alongside static if. A draft proposal is attached (Static Loops.p=
df). In brief, though, the goal is to provide an alternative to templ=
ate recursion that more closely models the runtime language, but forces loo=
p unrolling during translation. For example, the following function w=
ould do something like boost.fusion's for_each:<br><br>template<typename=
F, typename ... Types><br>void for_each(tuple<Types...> Tuple, F =
f)<br>{<br> static for(size_t i =3D 0; i < sizeof...(Types); i++) =
{<br> f(get<i>(Tuple));<br> }<br>}<br><br>The=
"static for" tells the compiler to unroll the for loop during translation.=
Then, get<i> can be instantiated separately for each iteration=
.. The challenge to the proposal, which I've tried to address, is dete=
cting when a loop can be unrolled in this fashion.<br><br>I would be gratef=
ul for people's comments!<br><br>Thanks,<br>Clayton<br></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_39_23926584.1352667986154--
.
Author: Christof Meerwald <cmeerw@cmeerw.org>
Date: Sun, 11 Nov 2012 23:24:36 +0100
Raw View
On Sun, 11 Nov 2012 12:31:01 -0800 (PST), ClaytonGDavis@gmail.com wrote:
> I'd like to make a proposal that is complementary to N3329 (static if;
> available at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf), which
> is currently under consideration. I believe there is a strong case to be
> made that static iteration loops would fit nicely alongside static if. A
> draft proposal is attached (Static Loops.pdf). In brief, though, the goal
> is to provide an alternative to template recursion that more closely models
> the runtime language, but forces loop unrolling during translation. For
> example, the following function would do something like boost.fusion's
> for_each:
>
> template<typename F, typename ... Types>
> void for_each(tuple<Types...> Tuple, F f)
> {
> static for(size_t i = 0; i < sizeof...(Types); i++) {
> f(get<i>(Tuple));
> }
> }
Over on the Standard Discussion group under the "switch statements"
thread I mentioned some alternative approach, see
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/q4KhZaN9IOY/wVukypfFJBEJ
which would only require the addition of pack literals or constant
integral pack expressions (or whatever these would be called).
for_each could then be implemented as:
template<typename F, typename ... Types>
void for_each(tuple<Types...> Tuple, F f)
{
f(get<0 .. sizeof...(Types) - 1>(Tuple)) ...;
}
or using slightly different syntax as:
template<typename F, typename ... Types>
void for_each(tuple<Types...> Tuple, F f)
{
f(get<0 : sizeof...(Types)>(Tuple)) ...;
}
Well, you would also need to allow a pack expansion in an
expression-statement (for this example), but the main idea would be to
just add suitable syntax to write a range of integers as a pack (which
can then be expanded as usual). I believe this would be much easier to
implement than static for and might fit in more naturally into the
existing variadic template support and can be used in contexts where
"static for" can't be used (initializer lists) - and I am sure it will
please those who argue for brevity in C++'s syntax...
BTW, I am just thinking out loud here...
Christof
--
http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
--
.
Author: "Matt D." <matdzb@gmail.com>
Date: Thu, 15 Nov 2012 10:47:12 -0800 (PST)
Raw View
------=_Part_2105_1339955.1353005232386
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, November 11, 2012 9:31:01 PM UTC+1, Clayto...@gmail.com wrote:
>
> Hi All,
>
> I'd like to make a proposal that is complementary to N3329 (static if;
> available at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf), which
> is currently under consideration. I believe there is a strong case to be
> made that static iteration loops would fit nicely alongside static if. A
> draft proposal is attached (Static Loops.pdf). In brief, though, the goal
> is to provide an alternative to template recursion that more closely models
> the runtime language, but forces loop unrolling during translation. For
> example, the following function would do something like boost.fusion's
> for_each:
>
> template<typename F, typename ... Types>
> void for_each(tuple<Types...> Tuple, F f)
> {
> static for(size_t i = 0; i < sizeof...(Types); i++) {
> f(get<i>(Tuple));
> }
> }
>
> The "static for" tells the compiler to unroll the for loop during
> translation. Then, get<i> can be instantiated separately for each
> iteration. The challenge to the proposal, which I've tried to address, is
> detecting when a loop can be unrolled in this fashion.
>
> I would be grateful for people's comments!
>
Hi!
Certainly looks interesting!
Incidentally, this topic was briefly touched upon in this year's C++ and
Beyond discussion ("Alexandrescu, Meyers, Sutter: On Static If, C++11 in
2012, Modern Libraries, and Metaprogramming"), here:
http://channel9.msdn.com/Shows/Going+Deep/Alexandrescu-Meyers-Sutter-On-Static-If-C11-in-2012-Modern-Libraries-and-Metaprogramming
If you'd like to expand on the motivation/rationale aspect, feel free to
re-use references /* shameless plug ;-) */:
http://channel9.msdn.com/Forums/TechOff/Andrei-Herb-and-Scott-Got-C11-Questions/6947394a1f5845f18c7aa0a2015f6972
Best,
Matt
> Thanks,
> Clayton
>
--
------=_Part_2105_1339955.1353005232386
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>On Sunday, November 11, 2012 9:31:01 PM UTC+1, Clayto...@gmail.com wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Hi All,<br><br>I'd like to m=
ake a proposal that is complementary to N3329 (static if; available at <a h=
ref=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf" t=
arget=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/20=
12/<wbr>n3329.pdf</a>), which is currently under consideration. I bel=
ieve there is a strong case to be made that static iteration loops would fi=
t nicely alongside static if. A draft proposal is attached (Static Lo=
ops.pdf). In brief, though, the goal is to provide an alternative to =
template recursion that more closely models the runtime language, but force=
s loop unrolling during translation. For example, the following funct=
ion would do something like boost.fusion's for_each:<br><br>template<typ=
ename F, typename ... Types><br>void for_each(tuple<Types...> Tupl=
e, F f)<br>{<br> static for(size_t i =3D 0; i < sizeof...(Types); =
i++) {<br> f(get<i>(Tuple));<br> }<br>}<br><b=
r>The "static for" tells the compiler to unroll the for loop during transla=
tion. Then, get<i> can be instantiated separately for each iter=
ation. The challenge to the proposal, which I've tried to address, is=
detecting when a loop can be unrolled in this fashion.<br><br>I would be g=
rateful for people's comments!<br></blockquote><div><br>Hi!<br><br>Certainl=
y looks interesting!<br><br>Incidentally, this topic was=20
briefly touched upon in this year's C++ and Beyond discussion ("Alexandresc=
u,=20
Meyers, Sutter: On Static If, C++11 in 2012, Modern Libraries, and=20
Metaprogramming"), here:<br>http://channel9.msdn.com/Shows/Going+Deep/Alexa=
ndrescu-Meyers-Sutter-On-Static-If-C11-in-2012-Modern-Libraries-and-Metapro=
gramming<br>If you'd like to expand on the motivation/rationale aspect, fee=
l free to re-use references /* shameless plug ;-) */:<br>http://channel9.ms=
dn.com/Forums/TechOff/Andrei-Herb-and-Scott-Got-C11-Questions/6947394a1f584=
5f18c7aa0a2015f6972<br><br>Best,<br><br>Matt <br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><br>Thanks,<br>Clayton<br></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_2105_1339955.1353005232386--
.