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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-19 15:58:31

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart

> From: "Paul Mensonides" <pmenso57_at_[hidden]>

> The predefined manifest constants can be described in a 
> configuration file, but the command line arguments, which are 
> often generated from a variety of tools (make files, IDEs, 
> etc.), would be fragile at best.  IOW, you could start with 
> none, then have your build system generate a file with 
> everything defined on the command line--per source file--and 
> your editor could be on the lookout for changes to that file. 
>  Unfortunately, that would mean that automatic formatting 
> would change over time and the coupling among build system 
> and editor is very tight.  That doesn't seem viable.

Note that the formatting would only change if a macro definition expanded into a
significantly different syntactic entity based on the definition of another
macro.  In that case, the source code at the point of use is saying two (or
more) different things syntactically, and formatting would be inherently
ambiguous.

#if CONSTANT
  #define MACRO 1
#else
  #define MACRO 2
#endif

In either case, it doesn't really matter what the value of 'CONSTANT' is,
because it doesn't change the external syntactic effect of 'MACRO' which is
likely to be the scenario in nearly all cases.

BTW, I realize that this is not a simple problem for an editor, but I still
think that it can be done reasonably well for the purposes of formatting code.

> > Otherwise, I agree with what you're saying here, but the tradeoff 
> > isn't worth it.  I don't have a problem with Boost 
> providing the tools 
> > to apply the workaround (i.e. BOOST_SEMICOLON) locally.  I 
> don't even 
> > have a problem with Boost headers that define the types of macros 
> > we're talking about here #include'ing that definition--just 
> to make it 
> > as easy as possible for the user to apply it.  The main 
> difference is 
> > that the library source contains the pure form, and any 
> workarounds are explicit.
> 
> I think that's a reasonable approach.  BOOST_SEMICOLON does 
> seem like a workable solution.  It satisfies the need for a 
> semicolon where one is needed to keep editors happy and it 
> keeps the semicolon in/out issue away from all other macros.

Well, here's a BOOST_SEMICOLON definition, in case anyone is interested (no
#include-guard required):

// <boost/semicolon.hpp>

namespace boost { namespace empty { } }

#define BOOST_SEMICOLON \
    using namespace ::boost::empty \
    /**/

It doesn't introduce any names into the scope where it is used, and it can be
used any number of times in the same scope.  It can be used at namespace and
function scope, though it is not necessary at function scope.  It *can't* be
used in class scope, but it isn't necessary there either.

Regards,
Paul Mensonides