From: Eric Niebler (eric_at_[hidden])
Date: 2005-05-02 11:17:49
Gennadiy Rozental wrote:
> "Eric Niebler" <eric_at_[hidden]> wrote in message
>> 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
>>>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*
> It adds a level of indirection, right. You are using Boost.Range for support
> 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
> #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
-- Eric Niebler Boost Consulting www.boost-consulting.com