"Eric Niebler" <eric@boost-consulting.com> wrote
What about nested invocations for BOOST_FOREACH:
int a[100][200]; int sum = 0;
BOOST_FOREACH(int (&x)[200], a) BOOST_FOREACH(int i, x) sum += i;
?
Its a fair point but just as possible the other way: FOR_EACH(a){ BOOST_AUTO(& x, *_); // or int (&x)[200] = *_; FOR_EACH(x) sum += *_; }
I dont know of a reason to require conversions as in the example: short array_short[] = {1,2,3}; BOOST_FOREACH( int i, array_short ) { // The short was implicitly converted to an int } What is the point of the example?
Conversions aren't "required", they are allowed. The point is to show that the loop variable doesn't have to have the same type as the element type, it only must be convertible.
OK.
However maybe this is an advantage... because the iterator is exposed then more loop information is avaialable eg if _ == my_container::begin() etc., which is an advantage over simply having the element available so making things more versatile.
It makes BOOST_FOREACH harder to extend. Not every sequence that users may want to iterate has anything like an iterator which is dereferencable. It is currently possible to make such non-STL sequences work with FOREACH with little effort, but after this change it would be impossible.
Ok.. but the main use would be with standard containers I would guess. I cant argue about what users may require. I think that other collections (e.g boost::graph) work quite hard to try to be consistent with the std algorithms. Is there a motivating example in the documentation? regards Andy Little