Re: [Monotone-devel] Re: The new macro M is no good...

[Nathaniel Smith]

On Tue, Jul 26, 2005 at 10:40:53PM +0200, Florian Weimer wrote:
> * Nathaniel Smith:
> 
> > Well, yes, it's good advice.  But since M _cannot_ be a non-macro,
> 
> What is it doing, actually?  Maybe there's a completely different way
> to get things done.

It marks a variable as "being of interest"; if an invariant fails
within the scope of the M(), that variable's value will be dumped into
the debug log.  This is to help with the common problem that we get a
crash dump that says _that_ something bad happened, but there's no way
to tell what might have caused the problem.

So we have something like
 void invert_changeset(change_set const & cs, change_set & inverted)
 {
   M(cs);
   M(inverted);
   // code goes here
 }
very low impact, easy to convince people to sprinkle around, etc.
What M(cs) expands to is the reasonably scary:
  Musing<typeof(cs)> this_is_a_musing_fnord_objectLINENUMBER(cs, "cs", 
__FILE__, __LINE__, __PRETTY_FUNCTION__)
The debug info at the end cannot be achieved except via macrology; the
"programmers have to come up with a unique name for each object" thing
can't be avoided except via macrology too, and is important for the
"low programmer impact" criterion.  I'd be _very_ curious to see
another way to accomplish something like this :-).

(What'd be really handy were if there were a GNU extension __UNIQUE__,
which is a magic macro like __LINE__ or __FILE__, whose guarantee is
that it has a different value every time it is expanded.  __LINE__
almost works for this, but the current code gives confusing errors if
you say
  M(cs); M(inverted);
instead of
  M(cs);
  M(inverted);
This would be useful in any C++ code where you want to call some guard
code on exit from current scope, but have no other reason to
insantiate an object.)

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender