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

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

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Chris Uzdavinis

> "Paul Mensonides" <pmenso57_at_[hidden]> writes:
> 
> > It takes very little effort to manually format the code that you 
> > write, and any
> 
> I agree, but from that point on, you then have to remember to 
> not re-indent a region of code from the editor.

Which is fairly obvious in nearly all cases.  For example:

MACRO()

int f(...) { ... }

> Sprinkling 
> such problems throughout code simply adds to the burdon of 
> maintaining code.  It is a pain to keep having to go back 
> through the code and re-hand-indent certain lines after 
> auto-indenting a whole file or a region of it.

Why would you need to auto-indent a whole file?  The only good reason that I see
is if some sort of code generator that doesn't cater to user readable (e.g. the
preprocessor) produces a mass of code that needs reformatting.  In that case, it
only needs to be temporarily reformatted, and it doesn't matter if it isn't
quite perfect.

> > decent C++ programmer should be able to read the code formatted 
> > according to another's preferences--without reformatting it.
> 
> I can read the following code, but it says the wrong thing to 
> anyone who doesn't have familiarity with the internals of the macro.
> Assuming that SOME_MACRO1 is really a stand-alone statement 
> and has its semicolon provided by the macro:
> 
>    statement1;
>    SOME_MACRO1() // misleading lack of visible semicolon
>      statement2; // (this auto-indented by editor)
>    statement3;
> 
> This is more than a problem of just indenting statement2.  It 
> also gives the impression that SOME_MACRO1's expansion 
> somehow bleeds into statement2. 

In this case, it's in a statement list where you can have null statements, so it
doesn't matter if you put it there or not--it doesn't effect the design of the
macro.  When it affects the design of the macro, that's when I start to have a
real problem, because it means that the designer purposely made it that way.

> A bad macro written the other extreme: 
> 
>   #define SOME_MACRO(X) if(X)
>   
>   int main()
>   {
>     SOME_MACRO2(5);  // misleading semicolon
>     statement2;     
>   }
> 
> However, I'd call this a poorly designed macro because it's 
> misleading and error prone.  My personal guidelines are:
> 
> 1) when a macro is logically its own statement,

I'm asserting that this is never the case.  The "logically" part above is a
testament to the prevailing viewpoint.  It isn't logically (and definitely not
physically) a statement.  It is a macro that expands to some code.  That code
might form a complete statement.  There is a significant distinction in
perspective.  That distinction doesn't always manifest itself at a semantic
level, but it sometimes does, and that is the root of the problem.  When it
does, it can create insidious errors that are far more difficult to fix.

> then the user should
>    provide the semicolon to aide in readability.  This makes it clear
>    that the macro is "done".  Therefore, I'd write SOME_MACRO1 to have
>    the user provide the semicolon.  This requires that the macro
>    actually be done and its effect doesn't spill into the following
>    code. 

No it doesn't.  The semicolon means nothing to the preprocessor, and the macro
can still effect the code that follows.

> 2) when a macro is intended to modify the code that follows it, then
>    it should not have visible trailing semicolons or they will mislead
>    the user.  It should be obvious from indentation that the macro is
>    being applied as a prefix to the code that follows, rather than a
>    self-contained statement.

A self-contained statement, BTW, would include the semicolon.  Otherwise, I
don't disagree with this part--mainly because putting the semicolon would be
erroneous in nearly all cases.

> > I don't have a problem with tools like these, BTW.  I have 
> a problem 
> > with altering the purity of a code base when it isn't absolutely 
> > necessary.
> 
> I consider myself somewhat of a language purist, but fail to 
> see how a semicolon affects "purity" in any way.  It's a 
> seperator.

It is a separator in the syntax of the underlying language.  It is not a
separator to the preprocessor.

> It seems clear to me how the semicolon's presence 
> (or lack thereof) can confuse maintence programmers,

Confuse maintenance programmers only if they have the flawed viewpoint that I've
been ranting about for years now.  Worst case scenario is that the maintenance
programmer has to look up the documentation for the macro.  Having to do that
enough times can change the perspective enough that it isn't a problem anymore.

Regards,
Paul Mensonides