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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk