|
Boost Users : |
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-06-30 14:40:55
> -----Original Message-----
> From: boost-users-bounces_at_[hidden]
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Dave Steffen
> 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.
Okay.
> 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".
Okay, let me get this straight. Are you saying that the macro invocation is
generating code that sometimes requires a closing semicolon to be applied and
sometimes not, or are you saying that you just want to be able to put the
semicolon there regardless? If it's the latter, then you should bite the bullet
and remove the semicolon. If it is the former, than the code generator should
yield the semicolon when necessary.
Regards,
Paul Mensonides
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net