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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-15 16:34:50

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Arkadiy Vertleyb

> > and by automatic formatting of some editors that many 
> people use (but 
> > many people don't).
> 
> I don't think it is correct to say that many C++ programmers 
> don't use Visual C++, for example.  It was already mentioned 
> on this list at some point that most people do, maybe as a 
> secondary compiler.  And, In Visual Studio it is quite 
> annoying to deal with constructs that do not adhere to the C++ syntax.

BTW, I use the VC++ IDE, but I rarely compile anything with VC++.  I use it
mainly for project management and editing.  You're right, it does a horrible job
at syntax highlighting and parentheses matching, but I use it precisely because
it does not automatically indent code in a way that I can't correct without it
constantly changing it back.

> > > > The problem that I have is not so much with catering to editors 
> > > > (though I am against that in principle), but with 
> catering to an 
> > > > incorrect viewpoint.
> 
> And this viewpoint is that a macro invocation is a function 
> call?

No, that a macro invocation is a kind of unit of work similar to a function
call.  For example,

#define max(a, b) ((a) < (b) ? (b) : (a))

... max(x, y) ...

Most programmers view this invocation as a macro that returns the greater of two
arguments.  That viewpoint is wrong, and is what leads, in this scenario, to
multiple evaluation problems.  What the macro does is expand to the expression
((a) ... ).

> I am not sure about Dave's case, but I am more 
> concerned about the case when a macro expands into a number 
> of template specializations.  So, when I am saying:
> 
> REGISTER_TYPE(x)
> 
> it is actually:
> 
> GENERATE_RELEVANT_TEMPLATE_SPECIALIZATIONS_FOR_TYPE(x)
> 
> Do you think requiring a semicolon would be incorrect here?

For example:

#define MAKE() \
    struct abc { }; \
    struct xyz { } \
    /**/

MAKE();

I find adding the first semicolon after 'abc', but not adding the second
semicolon after 'xyz' to be an abomination.  I find that worse that the case of
single struct definition (e.g.) because now the macro definition is inconsistant
within itself.  Despite that, I still think that in the single definition case
the macro should include the trailing semicolon--unless you intentionally want
to allow users to define variables (or types through 'typedef MACRO() x;')

Regards,
Paul Mensonides