Re: [boost] extra semicolons

From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2005-07-18 14:13:02

Arkadiy Vertleyb writes:
 > "Dave Steffen" <dgsteffen_at_[hidden]> wrote
 > >
 > >  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{};

 Ok, yes, that's another side of the issue.  I should have been
 clearer.

 "The issue is" (take 2 :-)  that there are some places where
 semicolons are required, and some where they are prohibited.  Given
 the existence of macros,

   A) should macros intended for use in places where a trailing
   semicolon is mandated, include that semicolon in their definitions?

   B) should macros intended for use in place where trailing macros
   are prohibited, take steps to allow a trailing semicolon because
   some users of the macro would like to put one there?

 > 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)?

 ... and what I attempted to say (and didn't very well) is that in
 places where null statements are allowed, yes, you're correct; the
 macro could include its own semicolon, and people who want add their
 own are allowed to....

 ... with a few exceptions.  As has been pointed out, 

      if (something)
        MACRO_INVOCATION();
      else
       ...

 is sensitive to how many semicolons end up at the end of the macro
 expansion.

 Whereas, in the case of function-defining macros and other odd
 things, you can't have a semicolon at all, because null statements
 aren't allowed there.  The question of why anyone would add a
 semicolon after such a macro is sort of what the hubbub is about;
 some people like me think it looks natural, others like Paul think
 it's an abomination. :-)

----------------------------------------------------------------------
Dave Steffen, Ph.D.       "There are two ways to write error-free
Software Engineer IV       programs; only the third one works."
Numerica Corporation            
ph [phone] x27     "Pie are not square. Pie are round. 
fax [phone]         Cornbread are square"
dgsteffen_at_[hidden]                    ... anon (usenet)
___________________
Numerica Disclaimer:
This message and any attachments are intended only for the individual
or entity to which the message is addressed.  It is proprietary and
may contain privileged information.  If you are neither the intended
recipient nor the agent responsible for delivering the message to the
intended recipient, you are hereby notified that any review,
retransmission, dissemination, or taking of any action in reliance
upon, the information in this communication is strictly prohibited,
and may be unlawful.  If you feel you have received this communication
in error, please notify us immediately by returning this Email to the
sender and deleting it from your computer.