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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-18 08:55:50

From: "Paul Mensonides" <pmenso57_at_[hidden]>
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart
> 
> > First, Paul contends you can fix code indenters, but how?
> > Really, when an editor sees a line that has no statement 
> > ending token, it has to assume it continues the previous 
> > line.
> 
> Any kind of tool that does analysis on C or C++ code, even if only at a
> syntactic level, has to be able to see through macro expansion.  This is a

Nope.  See below.

> result of the syntax not being static.  I.e. the syntax is not represented by
> the source code, but is derived from the source code by a preprocessor.
> 
> > After all, whitespace can appear throughout C++ code.  
> > I see no way for an indenter to "Do the Right Thing(TM)" in this case.
> 
> It has to be able to do macro expansion, it's that simple.  Whether or not that
> easy to integrate is another story, but it isn't impossible.  Anything less just
> means it is an robust, but generic, editor, rather than a robust C++ editor.

It is impossible.  There is no way for an editor to know the
manifest constants, predefined or otherwise, on which the
preprocessor will act to determine which code will be in effect
when compiling.  Thus, the editor cannot determine the definition
of the macro with any accuracy or consistency, so it cannot
ascertain the syntactic effect of the macro invocation.

There are but two choices for the editor: ignore the macro
invocation and indent based upon the code preceding it, or treat
the macro as an expression and not a statement.  Well, I suppose
there's a third choice, but that entails keeping a database of
user overrides.  However, that is untenable as changes introduced
into a VCS can completely disconnect the override data from the
text of the file.

Thus, by your definition, there cannot be a "robust C++ editor"
unless we eliminate the preprocessor.

> > Second, adding or omitting a semicolon will *not* change a 
> > programmer's understanding of the preprocessor.  I know many 
> > programmers who will simply add a semicolon or not as the 
> > compiler and indenter dicate.  They won't give it any more 
> > thought than that.
> 
> I have a serious problem catering to people that don't care also.  I don't have
> a problem with making them work a little as a result of the apathy.

Life's tough that way sometimes.  Seriously, absolute purity in
any endeavor usually serves no goal but to alienate most.  This
case isn't that extreme, I'll grant.  However, with sufficient
annoyance, one can turn away large numbers of C++ programmers
generally, and Boost users specifically.

Having said all of that, I find the following compelling:

From: "Peter Dimov" <pdimov_at_[hidden]>
> 
> If you let people add a semicolon after the macro, how can you change the 
> macro later in a way that doesn't tolerate a trailing semicolon? The 
> expansion of the macro is an implementation detail; the interface shouldn't 
> depend on a particular expansion.

I have, in fact, seen situations where this arose.  One has to
visit many files to remove trailing semicolons if one uses a
compiler that complains about the extras.

On that basis, I am convinced that semicolons should be kept
within the macro.  Indeed, I plan to follow that approach in my
own code henceforth, despite the formatting trouble it will
cause.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;