Re: [Boost-users] supressing "extra ;" warnings with GCC 3.4

From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2005-06-29 15:02:40

Paul Mensonides writes:
 > > -----Original Message-----
 > > From: boost-users-bounces_at_[hidden] 
 > > [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Dave Steffen
 > 
 > >  Yes, I've seen this in the GCC documentation.  Unfortunately, it
 > >  doesn't help if you're doing the sort of preprocessor metaprogramming
 > >  we're doing. In one case in particular, the end result of the macro
 > >  really is supposed to be a _function declaration_, not a section of
 > >  code.
 > > 
 > >  In another case, it shows up from the construct 
 > > 
 > > 
 > > #define NUM_SIG_CONNECTION_FUNCTIONS_FOR_MEMBERS(first,last) \
 > >   BOOST_PP_REPEAT_FROM_TO(BOOST_PP_ADD(first,1),BOOST_PP_ADD(last,2),\
 > >                           NUM_SIG_DECLARE_CONNECT,BOOST_PP_EMPTY)
 > > 
 > > 
 > >  I don't claim to understand everything that's going on here (even
 > >  remotely), but GCC 3.2 and 3.3 are very happy with the usage (in a
 > >  header file) 
 > > 
 > > 
 > > NUM_SIG_CONNECTION_FUNCTIONS_FOR_MEMBERS(0, MAX_SIGNAL_ARGS);
 > > 
 > >  while 3.4 complains about that semicolon.  What I'm asking is A) does
 > >  anyone know if 3.4 has a particular -Wno-extra-semicolon, or
 > >  equivalent, to turn off that warning; or B) what is the proper
 > >  preprocessor metaprogramming technique to silence the warning.
 > 
 > The proper technique is to get rid of the semicolon.  A macro
 > invocation is not an expression, though it may expand to one, and
 > it is not a function call.  Adding the semicolon and then trying to
 > get around the warning (which should be an error) only encourages
 > the view that macros invocations and function calls are equivalent.
 > Nearly all macro-related problems (other than name collision) are a
 > result of this fundamentally flawed perspective.  The use of all
 > caps should be make it obvious that a macro is involved.  Making
 > macro invocations appear more like function calls is evil--don't do
 > it.

 Right.  These macros are _not_ trying to look like function calls.
 Trying to make macros act like function calls _is_ evil, and we don't
 do that. Much. :-)  This is not the problem.

 These macros _are_ part of some metaprogramming constructs that are
 attempting to automate the declaration of a suite of fuctions; or,
 alterately, are the NUM_SIG_CONNECTION_FUNCTIONS_FOR_MEMBERS thing I
 mentioned above, which is part of our wrapper around Boost's signal
 library.

 I claim that our macros and use thereof is A) correct and B) safe.
 It just so happens that these macro constructs occasionally expand to
 something that has an extra semicolon, which triggers a warning in
 GCC 3.4 that we haven't seen before.  What I'm asking is this:
 assuming that our macros and useage thereof is correct, how do we 

          A) silence the GCC warning about extra semicolons, or 
          B) modify the construct so that the trailing semicolon is
          "legal", or at least "something that won't scare the
          compiler".

:-)

----------------------------------------------------------------------
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.