Gennadiy Rozental wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote in message news:4276407E.6030205@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