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

[Brian Downing]

On Tue, Jul 26, 2005 at 06:40:09PM -0700, Nathaniel Smith wrote:
> 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 :-).

As someone for whom this is quite minor macro hackery, a warning:

Traditionally Visual C++ (6 at least) has had __LINE__ not expand into a
literal number when the "Fix and Continue" debugging option is on.  This
is so all the __LINE__ references can be kept up to date as the code
changes.  Yes, this quite possibly flies in the face of ANSI, but they
do it anyway.  The only way to get around it is to turn that off, which
also disables the cool incremental compilation while debugging.

I found the uniquification behavior useful enough that I required people
to turn off that option, but I don't know if that's a tradeoff you want
to make.

Couldn't you also make it:
  Musing<typeof(cs)> this_is_a_musing_fnord_object_VARIABLENAME(cs, "cs", 
__FILE__, __LINE__, __PRETTY_FUNCTION__)

and both be save vs. VC++ damage and multiple calls per line?

-bcd
-- 
*** Brian Downing <bdowning at lavos dot net>