[boost] Re: Formal Review: FOREACH macro

From: Andrei Alexandrescu (See Website For Email) (SeeWebsiteForEmail_at_[hidden])
Date: 2005-05-02 16:58:12

Paul Mensonides wrote:
> 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.

Agreed. In the case of max, it's the syntactic similarity with a 
function call that lures people into making certain assumptions. Same 
goes about non-macro entities such as auto_ptr - "a = b;" looks like 
something that ain't.

By the way, it was FOREACH that inspired me to figure out a simple 
solution to max, which then Eric improved. It's basically like this:

#define max(a, b) (max_fn(true ? (a) : (b), false ? (a) : (b)))

which presto, nice-o passes the appropriate types to a template max_fn 
function that now can be smart about returning lvalues and so on.

Andrei