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