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

From: Chris Uzdavinis (chris_at_[hidden])
Date: 2005-07-18 10:00:16

"Paul Mensonides" <pmenso57_at_[hidden]> writes:

>> To humans, yes.  To editors, well, that's a hard problem.
>
> Not if editors can see through macro expansions, but I was referring to
> re-indenting by hand.

True, but that would require an editor to also be a project manager,
or at least to be able to parse and understand (correctly) a
makefile.  Otherwise, it wouldn't know what preprocessor macros are
defined or not from the command line, wouldn't know include paths,
etc.  That is hard enough to implement, but even harder to get fast
enough to be acceptible.

> I don't think that is an onerous task to split a line that is too
> long manually.

Well, I was thinking that if a variable name gets longer, it would
likely be changed in all places it's used, and for that a
search/replace may be applied.  Then a followup indentation might be
more convenient.

>  Also, in addition to reading code, one of the main purposes of
> indentation is to keep track of where you are when writing code.  If
> you format code as you go along, there is no need to re-indent the
> buffer.

That's assuming no automated editing techniques are being used
(editor macros, search/replace, IDE functionality to auto-refactor
code into its own function, etc.)

>  Likewise, removing trailing whitespace can be done without any
> formatting changes.

True, but re-indenting is a convenient way to get all this done at
once en masse, if you so prefer.  (Well, it seems you don't prefer,
but I do.)

> This is what plain old block identing is for.  You don't need a code
> formatter to do this.

It may make lines too long, and so you may wish to split a line, etc.

>> I don't worry too much if the whole file is generated, since 
>> I probably wouldn't be editing it anyway, but instead would 
>> be editing the spec file that was used to generate it.  Or 
>> perhaps I'd edit the generator itself.
>
> That's true, but you might be reading it to verify what the
> generator is doing.

You're right.  I've written a few code generators and spent a lot of
time making them format generated code cleanly, for precisely that
reason.  It also makes it easier to figure out precisely what's going
on or how to use the code if you sometimes take a peek.

>> By using the word "logically", I meant that "X becomes Y" can 
>> quite reasonably be described as being Y.
>
> I understand that, and that's what I'm disagreeing with.  There is a
> different degree of indirection that is important.

Ok, I'm willing to listen and try to be open minded.  What is it that
I'm missing?  Please consider this simple example:

  void log(char const * msg, char const * file, int lineno);

  #define LOG(X) log((X), __FILE, __LINE__)

I have a few questions for you because I am kind of stubborn but if I
feel convinced I'm wrong I'm willing to change.

1)  Do you think that the LOG() macro should contain a trailing
    semicolon?

2) I'm pretty sure you'll say #1, but which of the following examples
   do you prefer?

   int foo()
   {
     LOG("NO SEMICOLON HERE?")          // 1
     stuff();

     LOG("OR does this seem better?");  // 2
     more_stuff();
   }

3) Do you see harm if the macro does not contain the trailing
    semicolon?  If so, what harm is it?  Specifically, how does usage
    #2 above re-enforce bad understanding of macros?  (Or am I
    misconstruing the nature of your objection?)

4) What is the important degree of indirection that I would be missing
   by talking about the usage of the LOG macro as a call to the log
   function?  I understand that I could call it "a macro that expands
   to a call to the log function" but I don't think that anyone would
   be more enlightened by that.  Other than being more detailed about
   what's really happening, it's not clear to me what important
   mistake is being made that bothers you.  If our coding convention
   states that macros are uppercase, then we already know it's a
   macro, so simply repeating that is unnecessary, IMHO.

>> When you throw 
>> extra parenthesis after it and do other things to change how 
>> the preprocessor expands macros, then it blurs things up.  
>> But for the typical, standard usages of macros, this 
>> indistinction is not a problem.
>
> I totally disagree.  In fact, (if you're referring to something like
> full scale preprocessor metaprogramming) I'd go so far as to say the
> opposite.  In that case, any indistinction is far less of a problem
> than it is with "standard usages of macros".  Preprocessor
> metaprogramming is so obviously different than normal code that it
> hardly matters.  It is the normal, relatively simple, uses that can
> cause the most damage.

Could you apply this to my LOG macro above, to put it into a concrete
example of what's so bad?

... (snip a lot of interesting commentary) ...

-- 
Chris