ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Jan 13, 2010 at 08:27:33PM +0100, Marie Rognes wrote:
> Anders Logg wrote:
> >On Wed, Jan 13, 2010 at 06:39:56PM +0100, Marie Rognes wrote:
> >>noreply@xxxxxxxxxxxxx wrote:
> >>>------------------------------------------------------------
> >>>revno: 1443
> >>>committer: Anders Logg <logg@xxxxxxxxx>
> >>>branch nick: ffc-dev
> >>>timestamp: Wed 2010-01-13 17:00:13 +0100
> >>>message:
> >>> Remove \n in formats
> >>>modified:
> >>> ffc/cpp.py
> >>>
> >>I like the \n in formats. Makes more sense to me to have a line break
> >>after for instance "each assignment" than explicitly stating breaks
> >>in the code generation functions.
> >
> >I agree, but it becomes problematic in some cases. For example when we
> >insert things into the UFC format strings in the formatting stage:
> >
> >  /// Return the dimension of the finite element function space
> >  virtual unsigned int space_dimension() const
> >  {
> >%(space_dimension)s
> >  }
> >
> >Then we get things like
> >
> >  virtual unsigned int space_dimension() const
> >  {
> >    return 3;
> >
> >  }
> >
>
> Remove the "\n" in the format["return", "comment"] then ... and keep
> "iadd" and "assign" then?

I thought this was ok, but just found out it wasn't. It will lead to
things like

    // Compute element tensor
    A[0] += 0;
    A[1] += 0;
    A[2] += 0;
    A[3] += 0;
    A[4] += 0;
    A[5] += 0;
    A[6] += 0;
    A[7] += 0;
    A[8] += 0;

  }

Since we can't avoid the last \n.

So the general rule needs to be no \n in formatting rules and we add
it where we need it.

--
Anders

Attachment: signature.asc
Description: Digital signature