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

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2005-07-15 16:10:32

Much like Jody Hagins, I think, I agree with all of your points, except
that I place great value on automatic indentation and formatting, and a
even a single macro invocation that the editor cannot indent properly
makes the automatic indentation largely useless for the file.

The most obvious way for these tools to properly handle macro
invocations is for them to know to what the macro will expand.  But this
requires that the tool parse all of the necessary macro definitions.

The necessary macro definitions include all those defined in the file on
which the tool is operating as well as all those defined on files
included by the file on which the tool is operating.  Finding these
definitions alone would require that the tool do a very significant
amount of work, which would well take more time than users of the tool
would like to wait.  There is also the problem that some of the files
that the tool needs to read may have syntax errors, and even in this
case it is important that the tool can still format the code,
particularly code that is far away from the syntax error, reasonably
well.

Furthermore, this necessary set of macro definitions may also include
macros defined in other files that are not included by the file that is
being formatted (but will eventually be read by the preprocessor before
it sees the contents of the file being formatted), or even macros that
have not yet been written.

Clearly this approach is not feasible.

The current solution is for the macro invocation itself to provide
sufficient information, in the form of the absence or presence of a
semicolon, for the tool to properly format the code.

An alternative, which avoids the pitfalls of using a semicolon for this
purpose, is for the macro name itself to include the necessary
information, by conforming to some convention.  It is probably
sufficient to distinguish between only two types of macros:

 1. ones that produce compete declarations and/or statement

 2. ones that do not produce complete declarations or statements, and
   therefore must be used as a part of some other statement or
   declaration

One possible convention would be to suffix with an underscore the names
of macros that are in the first category.

With the assumption that macros have uppercase names, automatic
formatting tools could easily be modified to identify macro invocations
and indent them appropriately.

-- 
Jeremy Maitin-Shepard