Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-05-02 16:07:11

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Andrei
> Alexandrescu (See Website For Email)

> I don't like macros myself (ack! chaos! nooooo!...), but IMHO
All that I can do here is smile.

> I think the part of the discussion that focuses on arguments
> for or against macros is misplaced. We should ask ourselves
> about abstraction.

I'll reiterate something that you said a while back (paraphrasing). The
greatest harm that the macro mechanism (in C/C++) has caused is that it has kept
people from realizing the benefits of syntactic abstraction.

Furthermore, whether something is or isn't a macro is irrelevant. It is whether
it provides a useful abstraction that is documentable. As a macro, the name is
not going to collide with anything because of all-caps and the BOOST_ prefix.
Similarly, it isn't going to accidentally expand in any code. As I've said
before (paraphrasing), macro invocations are nothing like function calls except
in appearance, and nearly all other macro-related problems stem from developers
viewing them as if they are. Macros' "return values" are code snippets, not
values. E.g.

#define max(a, b) ((a) < (b) ? (b) : (a))

The problem here is not that 'max' has a problem with multiple evaluation; the
problem is that typical developers view 'max' as returning either 'a' or 'b'.
In other words, whether an abstraction is a macro is an important documentation
point, and the documentation of an abstraction, regardless of what it is (macro,
function, class, etc.), dictates the entirety of how it is to be used.

Regarding BOOST_FOREACH specifically: I think that it provides a useful
abstraction, and it costs very little in terms of source. As such, it is a good
utility to have around.

Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at