"Eric Niebler" <eric@boost-consulting.com> wrote in message news:4276407E.6030205@boost-consulting.com...
Gennadiy Rozental wrote:
1. Rvalues support I agree it's cool and "magical" - the way you added support for rvalues. But I believe it's actually misplaced efforts. IMO support for rvalues brings more harm than advantage. I could accidently or mindlessly (using some global replacement in sources, for example) introduce rvalue in BOOST_FOREACH statement and compiler wouldn't warn me. Now I am paying for an unnessesary copying. while exist perfectly good alternative that doesn't require it:
my_collection_type my_function(); ...
my_collection_type const& v = my_function()
BOOST_FOREACH(... , v ) { }
In addition eliminating rvalues support will signicantly simplify implementation and as a result speed up compilation.
There is an important usage scenario that requires iteration over rvalue containers ... when you don't know the type of the container. With the ragex_lib (in boost-sandbox), you can filter and transform a range *in place* and then immediately iterate over it. Consider:
BOOST_FOREACH(..., v | filter(my_pred()) | transform(my_func())) { }
Hopefully soon enough we may be able to write auto const& r = v | filter(my_pred()) | transform(my_func()); BOOST_FOREACH(..., r ) { }
Here, filter and transform are range adaptors, built on top of filter_iterator and transform_iterator. The type of the container is complicated, but you don't have to mention it anywhere because FOREACH correctly handles rvalues.
This is very powerful.
And dangerous. Cause allows developer to "forget" about an extra copy. I guess I could live with it. I wrap it into my own header and disable rvalues by definining appropriate macros
2. Usage of Boost.Range
I understand why FOREACH is using Boost.Range, but: a) In many (most) cases I (and any other developer now) working with stl containers and wouldn't need any extra help from boost.range for FOREACH to work properly. b) Usage of Boost.Range introduces an extra dependency on ... Boost.Range and everything it depends on in its' turn (including all portability limitations). I for one couldn't afford this dependency, c) Usage of Boost.Range adding a level of indiration and slightly complicate am implementation
Actually, I switched to Boost.Range to make the implementation *less* complicated.
It adds a level of indirection, right. You are using Boost.Range for support legacy arrays and extencibility. If you would stick with col.begin() and col.end() it would be simpler.
I am not going to propose to eliminate this dependency completely. But I think we need to make it optional.
What do you mean by and optional dependency on Boost.Range?
#ifndef BOOST_FOREACH_NO_BOOST_RANGE_DEPENDENCY or #ifndef BOOST_FOREACH_NO_EXTENCIONS Gennadiy