[boost] Re: Formal Review: FOREACH macro

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-05-02 10:22:03

"Eric Niebler" <eric_at_[hidden]> wrote in message 
news:4276407E.6030205_at_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