Re: [boost] Macros at namespace scope: trailing semicolon?

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-16 17:22:32

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Andy Little

> > I wouldn't mind this approach.  In fact, I kind of like it. 
>  It puts 
> > the appropriate emphasis on a macro's syntactic effect.  
> But I don't 
> > think that it will help the various problems that people have (like 
> > extra semicolons) or editor issues.  For example, if a 
> macro expands 
> > to a function definition, then there shouldn't be a 
> semicolon, which 
> > puts us squarely back in the situation we have now.
> 
> Not sure I understand this. The two macros should be classed 
> separately, consulting the grammar for the correct useage.

The problem is that users wouldn't be able to put a semicolon after this...

#define MACRO() void f() { }

MACRO(); // error

...which is the same situation, regardless of what MACRO expands to, that we
have now.  Some people think that its more natural to put the semicolon, and
some have editor problems without the semicolon.

> I'm guessing that David Abrahams macro expands to a 
> simple-declaration in the grammar( if the semi-colon is 
> included, else it would be incomplete grammatically), 
> therefore it should include the semicolon, which is the only 
> mandatory part incidentally. However the macro as 
> function-definition is grammatically complete without it.
> Of course with this approach macros would ideaaly be complete 
> grammar entities, which is much neater than trailing semicolons IMO.

Even without the semicolon, you can still match a structure declaration (without
a semicolon) to a grammar production.  It just isn't a more-or-less standalone
grammar production.

I do like this approach, though.  It gives a rigorous syntactic meaning where
there isn't one inherently.  One thing that concerns me, however, is that not
all macro expansions match a single grammar production (e.g. a class definition
with an out-of-line member function definition after it), and defining a macro
in terms of a lower-level grammar production implies that it can be used like
that grammar production.  For example,

#define MAKE(id) struct id { }

MAKE(abc) xyz;

In most cases, I don't think that allowing this is the intention (though
sometimes it is), so I think you'd have to stipulate that the matched grammar
production is as high-level as possible yet still achieve the basic intent.

Regards,
Paul Mensonides