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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-07-15 00:06:36

David Abrahams <dave_at_[hidden]> writes:

> I am defining a macro, 
>
>   BOOST_PARAMETER_KEYWORD(tag_namespace, name)
>
> that declares a keyword for the Parameter library.  It has to be used
> at namespace scope.  I have the option to define it so that correct
> usage requires a trailing semicolon, or so that the trailing semicolon
> is forbidden.  Unfortunately I don't have the ability to make it
> optional.  Which should I choose?
>
> IMO there's no chance of confusing it with a function call, since a
> function call would be illegal in the context in which it's used, and
> people are naturally more likely to add a semicolon without thinking
> about it, and if I design the macro so that a semicolon is required it
> will interact more smoothly with editors and pretty-printers.  So I
> can't see any good reason not to require the semicolon.  Arguments?

OK, here's a argument against: requiring the semicolon makes it
impossible to define a macro that expands to nothing. For instance, if
we required the semicolon in BOOST_MPL_AUX_LAMBDA_SUPPORT:

    template< typename T, typename U = int > struct f
    {
        typedef T type[sizeof(U)];
        BOOST_MPL_AUX_LAMBDA_SUPPORT(2, f, (T,U));
                                                ^^
    };

then for comforming compilers we would have to come up with something
like

    #define BOOST_MPL_AUX_LAMBDA_SUPPORT( arity, name, args ) \
    typedef BOOST_PP_CAT( ugly_ugly_hack, __LINE__ ) \
    /**/

and hope that user will never have a class member named
'ugly_ugly_hackNN'. Besides being conceptually unclean and
theoretically conflict-prone, this would also have an unpleasant
effect of not being able to get a "clean" version of the code by
simply preprocessing the file under a proper configuration (the MPL
way to generate "ideal" versions of the preprocessed headers for
conforming compilers).

-- 
Aleksey Gurtovoy
MetaCommunications Engineering