|
Boost : |
From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-07-18 13:51:33
"Dave Steffen" <dgsteffen_at_[hidden]> wrote
> Arkadiy Vertleyb writes:
> > Hi all,
> >
> > Not having extra semicolons is one of the strongest arguments
> > against incuding a trailing semicolon into a statement-generating
> > macro. Can anybody explain why having an extra semicolon is
> > considered a potential problem by some compilers? Isn't null as
> > good as any other number? Shouldn't an empty statement be
> > considered as good as any other statement?
>
> Ths issue is IIRC and AFAIK macros that are used outside of any
> statement blocks, i.e. the thing David Abrahams suggested that
> spawned this whole thread. Something like a macro that declares or
> defines a function:
>
> #define MAKEFOO inline void foo () { ... }
>
> and then simply used as:
>
> (... other inline functions, for example ...)
> MAKEFOO;
>
>
> The point is that after macro expansion, that semicolon I put in
> after the macro invocation isn't valid, because I'm not allowed to
> have a null statement (or any other kind of statement) at this point
> in the file.
>
> The presence or absence of that semicolon is what the fuss has been
> about. :-)
I tought it was about placing a trailing semicolon inside or outside a macro
definition, something like:
#define MACRO struct x{}
versus
#define MACRO struct x{};
So that it is used
MACRO(); // works nice with editors
or
MACRO() // more consistent
My point is that it would be possible to have both possibilities if empty
statements were allowd. The question was why are they not (by some
compilers)?
Regards,
Arkadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk