From: Joel (joel_at_[hidden])
Date: 2005-05-02 14:06:09
Andrei Alexandrescu (See Website For Email) wrote:
> Dave Harris wrote:
>> BOOST_FOREACH( int i, vec )
>> cout << i;
>> for (iterator i = vec.begin(); i != vec.end(); ++i)
>> cout << *i;
>> the macro just doesn't seem worth it.
> In fairness, it's
> for (vector<ArbitrarilyComplexType>::iterator i = vec.begin(); i !=
> vec.end(); ++i)
> cout << *i;
> And add to that that for is more general (in potentially harmful ways)
> because the iterator can be freely modified inside the loop. Often,
> that's not what you wanna.
> I don't like macros myself (ack! chaos! nooooo!...), but IMHO it's
> unfair to label FOREACH as macro-heavy machinery. The macro is but one
> layer behind which there's good non-macro stuff.
> I think the part of the discussion that focuses on arguments for or
> against macros is misplaced. We should ask ourselves about abstraction.
> That's the good thing. Does BOOST_FOREACH offer a good abstraction? Dave
> Harris says it's not enough, and I think that's the proper focus of
> discussion. (As a contrast, think of the boost initialization library. I
> doesn't use macros but I consider it way more dangerous, less useful,
> and offering less of an abstraction.) I think BOOST_FOREACH does offer a
> good, useful abstraction, that the disadvantages ot it using a macro are
> assuaged by good handling of macro-related problems and good taste in
> design, so if I have voting power around here, I'd vote for :o).
Of course you have ;)
I *used* to hate macros. The world would be a better place without them.
They don't have scope, convention requires them to be in ugly ALL_CAPS,
and prefix them with something like BOOST_ to avoid name clashes.
There are obscure gotchas like not being able to use templates with
commas, they need those yucky backslashes when you have to define
multi-line macros, they are a pain to debug (an error in macro code
takes you to the macro incocation, not the macro itself), etc, etc.
I *used* to believe that someday, macros will be replaced by true
c++ language facilities. "inline" code was a remarkable first start.
I *used* to believe that the more we let macros proliferate, the more
difficult it will be to dismantle this ugly relic of the past when
that time comes. Now I question that. Why don't we simply improve
the PP instead? Sure, macros, and the PP in general, are severely
problematic. Let's fix them!
The boost PP made me realize that macros *are* good when used
appropriately and intelligently. It also made me realize that
there are things we can do now that is not possible, or at least
not practical to do without macros. FOREACH is one of them.
*** I vote *yes* to accepting BOOST_FOREACH into boost. ***
Someday, when we have an improved PP, we will have a more potent
tool to use for writing libraries and facilities. Macros are a
simple yet powerful code generation mechanism. Facilities like
what's BOOST_FOREACH now, can behave like real language extensions.
With proper PP scopes (or maybe namespaces), we can get rid of the
ugly ALL_CAPS and BOOST_ prefix naming conventions. Then, it can
be spelled simply as 'foreach'. A library based facility is always
preferrable over a language extension.
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk