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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-19 05:40:22

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart

> > 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.

> > 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.

The editor can't automatically determine command line arguments or macros
predefined by the compiler (or compiler) to be used, that's true.  Those would
have to be supplied, but the rest can be done.  Some environments already do it
with varying degrees of success for other reasons.  I have seen it done where it
is fast enough.  I've yet to see it done where it was good enough though, but I
do think it's possible.

> 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.

The third option is to use an explicit workaround in the code that uses the
macro.

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

No, there can be, it's just that some of it has to come from a configuration
file.

> > 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 is a case where purity, in this small way, can be achieved without breaking
code on a bunch of compilers.  The syntax of C or C++ is dynamic, because of the
preprocessor, and that's just the way it is.  An editor that cannot handle that
is deficient when macros come into play.  Such editors may or may not be worth
fixing, but as they are now, that is a deficiency.  This deficiency can be
worked around in two places: 1) in the library, thus subjecting all users
regardless of the editor they use to the workaround, or 2) in the user code (or
a user library) of those users that use these particular editors.  I don't have
a problem with workarounds--well, I do, but I realize that they are a necessary
evil--but I do have a potential problem with the location of some workarounds
and how explicit (or not) that they are.

> 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.

I find it unlikely that this particular thing would be the one thing to tip the
balance away from someone using Boost, and I think you'd agree with that.
Otherwise, I agree with what you're saying here, but the tradeoff isn't worth
it.  I don't have a problem with Boost providing the tools to apply the
workaround (i.e. BOOST_SEMICOLON) locally.  I don't even have a problem with
Boost headers that define the types of macros we're talking about here
#include'ing that definition--just to make it as easy as possible for the user
to apply it.  The main difference is that the library source contains the pure
form, and any workarounds are explicit.

> > 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.

To be the devil's advocate, it isn't very hard to keep a "namespace-scope macro"
requiring a semicolon in the face of change, if being able to add a semicolon is
a priority for you.

Regards,
Paul Mensonides