[std-proposals] range-for should call for_each function if it has a one?

[e***@live.com]

I think it is painful and noisy to write iterators in order to support
range-for loop.

Here are my reasons:
1: semantics of range-for loop are not necessarily equivalent to access
every iterator in the range.
2: For many containers, defining iterators are harder than defining the
range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even lists, using
iterators to traverse the entire container lose a huge amount of
performance compared to define a universal for_each function.

For example, if I have a binary search tree:

template<typename T>
class bst
{
};


template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}



bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each" function
is defined for the container. If it does have one, call this first.
sum+=ele;

this will be equivalent to:

bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});

[Gašper Ažman]

The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to support
range-for loop.
1: semantics of range-for loop are not necessarily equivalent to access
every iterator in the range.
2: For many containers, defining iterators are harder than defining the
range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even lists,
using iterators to traverse the entire container lose a huge amount of
performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each" function
is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?utm_medium=email&utm_source=footer>
.

[e***@live.com]

But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to support
range-for loop.
1: semantics of range-for loop are not necessarily equivalent to access
every iterator in the range.
2: For many containers, defining iterators are harder than defining the
range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even lists,
using iterators to traverse the entire container lose a huge amount of
performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each" function
is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Gašper Ažman]

In the generator case it gets optimized away in most cases, and in others
its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to support
range-for loop.
1: semantics of range-for loop are not necessarily equivalent to access
every iterator in the range.
2: For many containers, defining iterators are harder than defining the
range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even lists,
using iterators to traverse the entire container lose a huge amount of
performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?utm_medium=email&utm_source=footer>
.

[e***@live.com]

Even so, the std containers do not define a standard interface for this.
Also, range-for loop won't use coroutine to call your function as well. A
standard interface must be defined before this being achieved.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in others
its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to support
range-for loop.
1: semantics of range-for loop are not necessarily equivalent to access
every iterator in the range.
2: For many containers, defining iterators are harder than defining the
range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even lists,
using iterators to traverse the entire container lose a huge amount of
performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?utm_medium=email&utm_source=footer>
.

[e***@live.com]

also, std::for_each is a function already defined in the standard library,
calling this won't add anything compared to add coroutine.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in others
its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to support
range-for loop.
1: semantics of range-for loop are not necessarily equivalent to access
every iterator in the range.
2: For many containers, defining iterators are harder than defining the
range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even lists,
using iterators to traverse the entire container lose a huge amount of
performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Gašper Ažman]

Adding customization points to the language is a "you better have a really
really good reason" kind of thing. If another feature already provides a
way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.

In this case, it's easy to see how

for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}

does its job just fine, without an extra customization point.

Post by e***@live.com
also, std::for_each is a function already defined in the standard library,
calling this won't add anything compared to add coroutine.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in others
its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to support
range-for loop.
1: semantics of range-for loop are not necessarily equivalent to
access every iterator in the range.
2: For many containers, defining iterators are harder than defining
the range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even lists,
using iterators to traverse the entire container lose a huge amount of
performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org?utm_medium=email&utm_source=footer>
.

[e***@live.com]

But, how could you define range-for loop for the type directly (for example
like std::deque) instead of using a coroutine of that type.

std::deque<int> d;
std::size_t sum(0):
for(const auto &ele : d)
sum+=0;

If you can't, it would be painful to write this for generic code?

Post by Gašper Ažman
Adding customization points to the language is a "you better have a really
really good reason" kind of thing. If another feature already provides a
way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.

Post by e***@live.com
also, std::for_each is a function already defined in the standard
library, calling this won't add anything compared to add coroutine.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in
others its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to
support range-for loop.
1: semantics of range-for loop are not necessarily equivalent to
access every iterator in the range.
2: For many containers, defining iterators are harder than defining
the range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even lists,
using iterators to traverse the entire container lose a huge amount of
performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Gašper Ažman]

By returning a fat iterator that encapsulates the generator from begin(),
and a sentinel that checks it against the generator's end() from end(). It
only takes a few lines of code, and I bet boost can provide a facade that
vanishes in codegen pretty easily.

Or, you know, just use std::for_each and expect it to be customized for
your type if you want generic code.

That said, feel free to propose this, but I personally don't see enough
justification to reserve yet another name in the language, because that's
what the current customization points do.

G

Post by e***@live.com
But, how could you define range-for loop for the type directly (for
example like std::deque) instead of using a coroutine of that type.
std::deque<int> d;
for(const auto &ele : d)
sum+=0;
If you can't, it would be painful to write this for generic code?

Post by Gašper Ažman
Adding customization points to the language is a "you better have a
really really good reason" kind of thing. If another feature already
provides a way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.

Post by e***@live.com
also, std::for_each is a function already defined in the standard
library, calling this won't add anything compared to add coroutine.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in
others its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to
support range-for loop.
1: semantics of range-for loop are not necessarily equivalent to
access every iterator in the range.
2: For many containers, defining iterators are harder than defining
the range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even
lists, using iterators to traverse the entire container lose a huge amount
of performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org?utm_medium=email&utm_source=footer>
.

[e***@live.com]

I don't think it is the point about coroutine. It is about the interface
for containers of range-for loop. The current standard must use iterators
for containers to iterator the entire container. You have to define a
standard interface for this in order for all containers to write customized
code to support these kinds of usage which is lacking in the standard. No
matter you use coroutine or for-each, it won't solve the issue directly.

Post by Gašper Ažman
By returning a fat iterator that encapsulates the generator from begin(),
and a sentinel that checks it against the generator's end() from end(). It
only takes a few lines of code, and I bet boost can provide a facade that
vanishes in codegen pretty easily.
Or, you know, just use std::for_each and expect it to be customized for
your type if you want generic code.
That said, feel free to propose this, but I personally don't see enough
justification to reserve yet another name in the language, because that's
what the current customization points do.
G

Post by e***@live.com
But, how could you define range-for loop for the type directly (for
example like std::deque) instead of using a coroutine of that type.
std::deque<int> d;
for(const auto &ele : d)
sum+=0;
If you can't, it would be painful to write this for generic code?

Post by Gašper Ažman
Adding customization points to the language is a "you better have a
really really good reason" kind of thing. If another feature already
provides a way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.

Post by e***@live.com
also, std::for_each is a function already defined in the standard
library, calling this won't add anything compared to add coroutine.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in
others its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to
support range-for loop.
1: semantics of range-for loop are not necessarily equivalent to
access every iterator in the range.
2: For many containers, defining iterators are harder than defining
the range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even
lists, using iterators to traverse the entire container lose a huge amount
of performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Gašper Ažman]

Post by e***@live.com
I don't think it is the point about coroutine. It is about the interface
for containers of range-for loop. The current standard must use iterators
for containers to iterator the entire container.

Yes, that's the point. The ranged for is not a magic construct, it uses the
standard interface. Let's not add another interface.

Post by e***@live.com
You have to define a standard interface for this in order for all
containers to write customized code to support these kinds of usage which
is lacking in the standard. No matter you use coroutine or for-each, it
won't solve the issue directly.

It does - you can easily write a facade that will implement your begin()
and end() directly on the container, if you want. My suggestion was that
putting that facade into boost to wrap a simple coroutine that yields
references to successive elements is a relatively simple exercise and it
*solves your problem* without introducing a separate way to interpret
ranged for-loops that may actually break code because it prefers the new
interface.

Post by e***@live.com

Post by Gašper Ažman
By returning a fat iterator that encapsulates the generator from begin(),
and a sentinel that checks it against the generator's end() from end(). It
only takes a few lines of code, and I bet boost can provide a facade that
vanishes in codegen pretty easily.
Or, you know, just use std::for_each and expect it to be customized for
your type if you want generic code.
That said, feel free to propose this, but I personally don't see enough
justification to reserve yet another name in the language, because that's
what the current customization points do.
G

Post by e***@live.com
But, how could you define range-for loop for the type directly (for
example like std::deque) instead of using a coroutine of that type.
std::deque<int> d;
for(const auto &ele : d)
sum+=0;
If you can't, it would be painful to write this for generic code?

Post by Gašper Ažman
Adding customization points to the language is a "you better have a
really really good reason" kind of thing. If another feature already
provides a way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.

Post by e***@live.com
also, std::for_each is a function already defined in the standard
library, calling this won't add anything compared to add coroutine.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in
others its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to
support range-for loop.
1: semantics of range-for loop are not necessarily equivalent to
access every iterator in the range.
2: For many containers, defining iterators are harder than
defining the range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even
lists, using iterators to traverse the entire container lose a huge amount
of performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/63319859-3f0a-4799-90e9-fd699ee89f29%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/63319859-3f0a-4799-90e9-fd699ee89f29%40isocpp.org?utm_medium=email&utm_source=footer>
.

[e***@live.com]

It won't. std::deque, std::set, std::map they all do not define this.

Post by Gašper Ažman

Post by e***@live.com
I don't think it is the point about coroutine. It is about the interface
for containers of range-for loop. The current standard must use iterators
for containers to iterator the entire container.

Yes, that's the point. The ranged for is not a magic construct, it uses
the standard interface. Let's not add another interface.

Post by e***@live.com
You have to define a standard interface for this in order for all
containers to write customized code to support these kinds of usage which
is lacking in the standard. No matter you use coroutine or for-each, it
won't solve the issue directly.

It does - you can easily write a facade that will implement your begin()
and end() directly on the container, if you want. My suggestion was that
putting that facade into boost to wrap a simple coroutine that yields
references to successive elements is a relatively simple exercise and it
*solves your problem* without introducing a separate way to interpret
ranged for-loops that may actually break code because it prefers the new
interface.

Post by e***@live.com

Post by Gašper Ažman
By returning a fat iterator that encapsulates the generator from
begin(), and a sentinel that checks it against the generator's end() from
end(). It only takes a few lines of code, and I bet boost can provide a
facade that vanishes in codegen pretty easily.
Or, you know, just use std::for_each and expect it to be customized for
your type if you want generic code.
That said, feel free to propose this, but I personally don't see enough
justification to reserve yet another name in the language, because that's
what the current customization points do.
G

Post by e***@live.com
But, how could you define range-for loop for the type directly (for
example like std::deque) instead of using a coroutine of that type.
std::deque<int> d;
for(const auto &ele : d)
sum+=0;
If you can't, it would be painful to write this for generic code?

Post by Gašper Ažman
Adding customization points to the language is a "you better have a
really really good reason" kind of thing. If another feature already
provides a way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.

Post by e***@live.com
also, std::for_each is a function already defined in the standard
library, calling this won't add anything compared to add coroutine.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in
others its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to
support range-for loop.
1: semantics of range-for loop are not necessarily equivalent to
access every iterator in the range.
2: For many containers, defining iterators are harder than
defining the range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even
lists, using iterators to traverse the entire container lose a huge amount
of performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/63319859-3f0a-4799-90e9-fd699ee89f29%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/63319859-3f0a-4799-90e9-fd699ee89f29%40isocpp.org?utm_medium=email&utm_source=footer>
.

[e***@live.com]

maybe it requires a std::range(C) just like std::begin(C), std::end(C). The
for-each loop will call std::range(C) to extend the code to that code you
write before.

Post by Gašper Ažman
By returning a fat iterator that encapsulates the generator from begin(),
and a sentinel that checks it against the generator's end() from end(). It
only takes a few lines of code, and I bet boost can provide a facade that
vanishes in codegen pretty easily.
Or, you know, just use std::for_each and expect it to be customized for
your type if you want generic code.
That said, feel free to propose this, but I personally don't see enough
justification to reserve yet another name in the language, because that's
what the current customization points do.
G

Post by e***@live.com
But, how could you define range-for loop for the type directly (for
example like std::deque) instead of using a coroutine of that type.
std::deque<int> d;
for(const auto &ele : d)
sum+=0;
If you can't, it would be painful to write this for generic code?

Post by Gašper Ažman
Adding customization points to the language is a "you better have a
really really good reason" kind of thing. If another feature already
provides a way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.

Post by e***@live.com
also, std::for_each is a function already defined in the standard
library, calling this won't add anything compared to add coroutine.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in
others its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to
support range-for loop.
1: semantics of range-for loop are not necessarily equivalent to
access every iterator in the range.
2: For many containers, defining iterators are harder than defining
the range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even
lists, using iterators to traverse the entire container lose a huge amount
of performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2f9e546-638d-4ebb-b0c9-f1eb329717f0%40isocpp.org?utm_medium=email&utm_source=footer>
.

[e***@live.com]

I just want to write:

for (auto& element : x) {
element += 1;
}

I don't want to write:
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}

This code won't work withe generic code.

Post by Gašper Ažman
Adding customization points to the language is a "you better have a really
really good reason" kind of thing. If another feature already provides a
way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.

Post by e***@live.com
also, std::for_each is a function already defined in the standard
library, calling this won't add anything compared to add coroutine.

Post by Gašper Ažman
In the generator case it gets optimized away in most cases, and in
others its only the price of a (predicted) function call. No different than
calling a for_each with a synthesized lambda that you invoke on every
element.

Post by e***@live.com
But context swapping is slow.

Post by Gašper Ažman
The solution for this is already targeted by the generators of coroutines.

Post by e***@live.com
I think it is painful and noisy to write iterators in order to
support range-for loop.
1: semantics of range-for loop are not necessarily equivalent to
access every iterator in the range.
2: For many containers, defining iterators are harder than defining
the range-for loop directly.
3: It is painful to write iterators to support simple data structures.
4: For containers like std::deque, std::set, std::map and even lists,
using iterators to traverse the entire container lose a huge amount of
performance compared to define a universal for_each function.
template<typename T>
class bst
{
};
template<typename T,typename Callback>
void inorder_traverse(const bstnode<T> *p,Callback &&F)
{
if(p->left())
inorder_travel(p->left(),F);
F(p->value());
if(p->right())
inorder_travel(p->right(),F);
}
template<typename T,typename Callback>
inline void for_each(const bst<T> &t,Callback &&F)
{
if(t.root())
inorder_traverse(t.root(),std::forward<Callback>(F));
}
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"
function is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});
--
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,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ba3d13b-3044-4223-afd0-218e8ba06893%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88165d50-83b4-4067-bec3-7c7dab15dce3%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b76fd5e-f3c3-4952-af81-3435456f48b7%40isocpp.org?utm_medium=email&utm_source=footer>
.

[f***@gmail.com]

There are cases where a for_each can be better/faster(/stronger) than
ranges: nested loops.

Emulating nested loops with ranges is slow because for each ++, the
iterator has to check if it has reached the end of the inner loop or not.

Post by Gašper Ažman
Adding customization points to the language is a "you better have a really
really good reason" kind of thing. If another feature already provides a
way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.

[Gašper Ažman]

I really don't see how this applies to generators from the coroutines TS,
and also how nested loops can somehow be written differently as a function
vs an iterator comparison.

Post by f***@gmail.com
There are cases where a for_each can be better/faster(/stronger) than
ranges: nested loops.
Emulating nested loops with ranges is slow because for each ++, the
iterator has to check if it has reached the end of the inner loop or not.

Post by Gašper Ažman
Adding customization points to the language is a "you better have a
really really good reason" kind of thing. If another feature already
provides a way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.
--

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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/71498824-6a5b-40ba-84db-4d4df72e2c94%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/71498824-6a5b-40ba-84db-4d4df72e2c94%40isocpp.org?utm_medium=email&utm_source=footer>
.

[f***@gmail.com]

Let's have an exemple:
Imagine you have a type that internally is a vector of vectors, and you
want to iterate over all its elements: https://gcc.godbolt.org/z/rXRID9
As you can see, the code with the foreach is both simpler to write and
gives better assembly.
I haven't run benchmarcks, but I can assure you that if the loop body is
small, the difference will be far from negligible.

It might seems a bit cumbersome to write a container like that and expect
people to always iterate on the inner elements, but that's exactly what a
Deque is and does (set and map are also similar).

So there is an interest into formalizing a "for_each" like approach that
does not rely on ranges and iterators.

Post by Gašper Ažman
I really don't see how this applies to generators from the coroutines TS,
and also how nested loops can somehow be written differently as a function
vs an iterator comparison.

Post by f***@gmail.com
There are cases where a for_each can be better/faster(/stronger) than
ranges: nested loops.
Emulating nested loops with ranges is slow because for each ++, the
iterator has to check if it has reached the end of the inner loop or not.

Post by Gašper Ažman
Adding customization points to the language is a "you better have a
really really good reason" kind of thing. If another feature already
provides a way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.
--

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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/71498824-6a5b-40ba-84db-4d4df72e2c94%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/71498824-6a5b-40ba-84db-4d4df72e2c94%40isocpp.org?utm_medium=email&utm_source=footer>
.

[e***@live.com]

Gasper wants to use coroutine instead of writing for_each. I think it is a
cool idea.

I think defining a range(C) coroutine like begin(C), end(C) as a standard
would be better.

Post by f***@gmail.com
Imagine you have a type that internally is a vector of vectors, and you
want to iterate over all its elements: https://gcc.godbolt.org/z/rXRID9
As you can see, the code with the foreach is both simpler to write and
gives better assembly.
I haven't run benchmarcks, but I can assure you that if the loop body is
small, the difference will be far from negligible.
It might seems a bit cumbersome to write a container like that and expect
people to always iterate on the inner elements, but that's exactly what a
Deque is and does (set and map are also similar).
So there is an interest into formalizing a "for_each" like approach that
does not rely on ranges and iterators.

Post by Gašper Ažman
I really don't see how this applies to generators from the coroutines TS,
and also how nested loops can somehow be written differently as a function
vs an iterator comparison.

Post by f***@gmail.com
There are cases where a for_each can be better/faster(/stronger) than
ranges: nested loops.
Emulating nested loops with ranges is slow because for each ++, the
iterator has to check if it has reached the end of the inner loop or not.

Post by Gašper Ažman
Adding customization points to the language is a "you better have a
really really good reason" kind of thing. If another feature already
provides a way to hook into already existing features without an additional
customization point, you'd expect the standard to avoid adding
customization points.
In this case, it's easy to see how
for (auto range = x.in_order_traversal(); auto& element : range) {
element += 1;
}
does its job just fine, without an extra customization point.
--

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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/71498824-6a5b-40ba-84db-4d4df72e2c94%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/71498824-6a5b-40ba-84db-4d4df72e2c94%40isocpp.org?utm_medium=email&utm_source=footer>
.

[f***@gmail.com]

I'm a bit doubtful about the speed of coroutines as generators

Post by e***@live.com
Gasper wants to use coroutine instead of writing for_each. I think it is a
cool idea.
I think defining a range(C) coroutine like begin(C), end(C) as a standard
would be better.

[Gašper Ažman]

The simple ones get inlined and you get perfect codegen.

Post by f***@gmail.com
I'm a bit doubtful about the speed of coroutines as generators

Post by e***@live.com
Gasper wants to use coroutine instead of writing for_each. I think it is
a cool idea.
I think defining a range(C) coroutine like begin(C), end(C) as a standard
would be better.
--

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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b49af51f-2404-43a6-8d69-f0c6de72d07f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b49af51f-2404-43a6-8d69-f0c6de72d07f%40isocpp.org?utm_medium=email&utm_source=footer>
.

[f***@gmail.com]

Exactly like the flattened iterator should also be inlined and lead to
perfect codegen but does not in practice?

Post by Gašper Ažman
The simple ones get inlined and you get perfect codegen.

Post by f***@gmail.com
I'm a bit doubtful about the speed of coroutines as generators

Post by e***@live.com
Gasper wants to use coroutine instead of writing for_each. I think it is
a cool idea.
I think defining a range(C) coroutine like begin(C), end(C) as a
standard would be better.
--

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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b49af51f-2404-43a6-8d69-f0c6de72d07f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b49af51f-2404-43a6-8d69-f0c6de72d07f%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Gašper Ažman]

No, it's better with coroutines, because they look like the inverted
for_each:

std::generator<reference> iterate() {
for (auto& v : data) {
for (auto& e : v) {
co_yield e;
}
}
}

The body of the for-loop gets pretty much directly pasted into the co-yield
section, after inlining, exactly the way the lambda does.

I'll try to prove it to you when I get home and have time to play with
this, I think godbolt has a coroutine-enabled compiler somewhere.

Post by f***@gmail.com
Exactly like the flattened iterator should also be inlined and lead to
perfect codegen but does not in practice?

Post by Gašper Ažman
The simple ones get inlined and you get perfect codegen.

Post by f***@gmail.com
I'm a bit doubtful about the speed of coroutines as generators

Post by e***@live.com
Gasper wants to use coroutine instead of writing for_each. I think it
is a cool idea.
I think defining a range(C) coroutine like begin(C), end(C) as a
standard would be better.
--

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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b49af51f-2404-43a6-8d69-f0c6de72d07f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b49af51f-2404-43a6-8d69-f0c6de72d07f%40isocpp.org?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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0a9411-4967-4f96-bbbe-9c2eaa13d0ad%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b0a9411-4967-4f96-bbbe-9c2eaa13d0ad%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Matthew Woehlke]

Post by e***@live.com
I think it is painful and noisy to write iterators in order to support
range-for loop.
[...]
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each" function
is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});

...and how, exactly, will you implement a `break` with this? Especially
if your implementation of `for_each` is using recursive calls?

[e***@live.com]

throw an exception and catch it :)

lol. better just use a coroutine.

Post by e***@live.com

Post by e***@live.com
I think it is painful and noisy to write iterators in order to support
range-for loop.
[...]
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"

function

Post by e***@live.com
is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});

...and how, exactly, will you implement a `break` with this? Especially
if your implementation of `for_each` is using recursive calls?
--
Matthew

[Gašper Ažman]

Matthew: thanks for the QED :)

Post by e***@live.com
throw an exception and catch it :)
lol. better just use a coroutine.

Post by e***@live.com

Post by e***@live.com
I think it is painful and noisy to write iterators in order to support
range-for loop.
[...]
bst<std::size_t> b;
std::size_t sum(0);
for(const auto &ele : b) // will check whether the "for_each"

function

Post by e***@live.com
is defined for the container. If it does have one, call this first.
sum+=ele;
bst<std::size_t> b;
std::size_t sum(0);
for_each(b,[&](const auto &ele)
{
sum+=ele;
});

...and how, exactly, will you implement a `break` with this? Especially
if your implementation of `for_each` is using recursive calls?
--
Matthew

--
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
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24692d6c-c68a-414e-9f65-6f25f21169e6%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24692d6c-c68a-414e-9f65-6f25f21169e6%40isocpp.org?utm_medium=email&utm_source=footer>
.