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: > >>[email protected] wrote: > >>>------------------------------------------------------------ > >>>revno: 1443 > >>>committer: Anders Logg <[email protected]> > >>>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
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : [email protected] Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
