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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-19 08:23:15

From: "Paul Mensonides" <pmenso57_at_[hidden]>
> > From: boost-bounces_at_[hidden] 
> > [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart
> 
> > 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.

The predefined manifest constants can be described in a
configuration file, but the command line arguments, which are
often generated from a variety of tools (make files, IDEs, etc.),
would be fragile at best.  IOW, you could start with none, then
have your build system generate a file with everything defined on
the command line--per source file--and your editor could be on
the lookout for changes to that file.  Unfortunately, that would
mean that automatic formatting would change over time and the
coupling among build system and editor is very tight.  That
doesn't seem viable.

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

Right.  A special comment token has been suggested.  That would
work, but it would require changes to the formatting code.

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

Yes.

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

I think that's a reasonable approach.  BOOST_SEMICOLON does seem
like a workable solution.  It satisfies the need for a semicolon
where one is needed to keep editors happy and it keeps the
semicolon in/out issue away from all other macros.

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

I suppose you're right, but that just adds ugliness to a macro in
order to make it so that clients can continue to add a semicolon.

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