Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2005-05-02 10:24:29


Dave Harris wrote:
>
> I too have a strong antipathy to macros. I don't reject them absolutely,
> but they need a very good justification. I can't see myself ever using
> BOOST_FOREACH because the problem it is solving isn't hard enough to
> warrant the obfuscation. Comparing:
>
> BOOST_FOREACH( int i, vec )
> cout << i;
>
> with:
>
> for (iterator i = vec.begin(); i != vec.end(); ++i)
> cout << *i;
>
> the macro just doesn't seem worth it.

In this simple example, I might agree with you. But see my reply to
Gennadiy for an example of something that BOOST_FOREACH can do that an
ordinary for loop, or even std::for_each, cannot.

> I have looked at the documentation and found it a bit superficial. For
> example, I can't tell whether the example above is actually supported. All
> the examples in the documentation have braces around the loop body: are
> those just the author's preferred style, or are they required by the
> macro? I looked at the implementation and I still can't tell. I prefer to
> omit braces when they are not required.

Braces around the loop body are not required. I could add that to the docs.

>
> I have not tried to use the macro. From the source, it looks like it
> injects a largish number of local variables into the code, and these will
> show up in the debugger and need to be understood to follow how the loop
> is progressing.

It injects 5 local variables. I haven't checked, but I suspect that some
can be optimized away sometimes. I'm not sure why users will need to
understand how FOREACH uses its hidden variables. Can you explain?

>
> For what it's worth, I think the design is impressive and if I had come up
> with it I'd be very proud. Congratulations. The problem is that it is too
> clever. It is using a sledgehammer to crack a nut.

This nut is an exceptionally tough one to crack. ;-)

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk