David Abrahams <dave@boost-consulting.com> 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