[boost] Re: Formal Review: FOREACH macro

From: Eric Niebler (eric_at_[hidden])
Date: 2005-05-02 11:17:49

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

Code that returns STL containers by value is already inefficient. Why 
prevent FOREACH from working with such code? I don't understand.

Besides, eliminating the rvalue requirement won't simplify the code 
because much of that machinery is needed anyway to prevent the macro 
args from being reevaluated. The rvalue stuff practically falls out of that.

I hope that you aren't reintroducing reevaluation bugs by "defining 
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.

Sure, and if we did away with FOREACH and used the for keyword, it would 
be simplier. And if we threw out for and used goto .... ;-)

The complexity is there for a reason. Being able to iterate over arrays, 
strings, containers, iterator ranges is a design goal. So is providing 
an extensibility mechanism.

> 
> 
>>>  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
> 

This doesn't even begin to answer my question, but maybe I should have 
been more specific. How would I implement the code to make the 
dependency on Boost.Range optional? And what sort of advice do I give 
people who want to extend FOREACH if the extensibility points are also 
optional?

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com