|
Boost : |
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-19 05:40:24
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
> IIRC someone else proposed a policy that Paul M. agreed with
> -- at least conditionally -- but I can't find it in the
> archives. Can somebody point me to it? Since Paul is a PP
> expert it makes sense to give anything he agrees with a second look.
The policy was (in cases where it makes any sense) for macros to be given a
strict syntactic definition in terms a direct correspondence with a C++ grammar
production. The reason that I find this attractive is that it gives a rigourous
syntactic definition to something that doesn't have one based upon its syntactic
representation to the preprocessor.
The main problem is that it wouldn't solve any of the problems here. The
secondary problem is that there is a significant difference between...
struct abc {
void f() { }
};
...and...
struct abc {
void f();
};
void abc::f() { }
...in terms of production depth. A direct match to a production for the former
is much more refined than a direct match for the latter. A tertiary problem,
which is directly related to this discussion, is what heuristic to apply to
choose the production, because you can obviously directly match a production to
both...
struct abc { }
..and...
struct abc { };
My opinion is that it should be decided based on whether there is an intended
external point of variability. I.e. if this is not intended
typedef MACRO(abc) xyz;
then the semicolon is not an external point of grammatical variability, and
'MACRO' should match the production that doesn't allow for this variability.
(In other words, it should include its own semicolon, and we're back to square
one.) The lesser the depth, the more restrictive in terms of external
variability, which would be the kind of abstract definition needed if a macro
*was* an abstraction rather than a simple shorthand way to say something, thus
allowing it to change more easily over time.
Regards,
Paul Mensonides
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk