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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-15 12:33:36

From: Thomas Witt <witt_at_[hidden]>
> 
> AFAICS the point this discussion revolves around is not whether somebody 
> is wrong or right it's all about how we value these arguments in 
> everyday life.

That sounds right.

> While I think that on a technical basis Paul is right, I value automatic 
> code indentation much higher than all the arguments in favour of not 
> requiring the semicolon. Yes it is more pure but in my experience it 
> causes way more trouble in practice then it does any good by educating 
> programmers about the nature of macros. And yes it is sad to tailor your 
> coding style to arguably insufficient tools but at the end of day there 
> is no perfect tool and we need to get a job done in the best possible 
> way given the circumstances.
> 
> As a sidenote I kind of doubt that making there usage looking 
> syntactically diffferent from function calls will educate users about 
> the way they work. To me doing away with the usual "macros are evil" 
> attitude" sounds like a lot more promising approach to me.

I was thinking similarly.

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.  After
all, whitespace can appear throughout C++ code.  I see no way for
an indenter to "Do the Right Thing(TM)" in this case.

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.

Thus, requiring that all macros be complete entities that *never*
require semicolons is a purist position that offers only
consistency, but at what cost?  Code will be indented oddly,
which can lead to misinterpretation, and habit will constantly
interfere.

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