ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Feb 26, 2013 at 02:26:35PM +0000, Florian Rathgeber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 26/02/13 09:33, Martin Sandve Aln￦s wrote:
> > Just want to chip in here. FYI I'm currently adding a new
> > representation to ffc based on lp:uflacs, where I reuse some of the
> > quadrature representation code and new generate tabulate_tensor
> > bodies with completely separate code. I'm using my own code
> > formatting utilities, which probably has its pros and cons. I've
> > also done some minor refactoring in ffc, so there will be a merge
> > soonish (when Anders gets the dolfin-ufc-geometry branch up to
> > speed). Hopefully this won't be difficult for you to merge with
> > your branch, I don't think it's too extensive.
>
> Thanks for the heads up, it sounds like once your branch gets merged
> things will be a bit easier for us. Is it the
> ffc-uflacs-ufc-geometry-merged branch?

Yes.

> > As for the language differences, I think it will be practical to
> > generate code kernels that are both C99 and C++ compatible:
> >
> > a) Usage of functions like sqrt, abs, pow from the std namespace.
> >
> > - Instead of using std::foo in the code, we can add "using
> > std::foo;" in code targeted for C++. Makes the generated code
> > cleaner as well.
>
> Where do you think the right place for this would be? FFC or ufc_utils?

I suggest a new header ufc_math.h. We're extending UFC with more than
just the one header. Right now, there's ufc.h and ufc_geometry.h.

> > b) Usage of C++ exceptions (only when hitting invalid orientation
> > markers).
> >
> > - This can be removed and checked on the dolfin side like
> > everything else, as I see it it's mainly there for a safe gradual
> > introduction of the orientation markers.
>
> We're not hitting this kernel in our code at the moment, so we could
> just ignore it for now.
>
> > c) Usage of the static keyword (which has a different meaning in
> > C99).
> >
> > - Are you sure?
> > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1012 I
> > think we can wrap global static declarations in an unnamed
> > namespace if the code is target for C++, and otherwise use the same
> > declarations.
>
> I think I was wrong about that, static seems to be a perfectly legal
> keyword also in C99 the way it's used in FFC generated code. It's a
> bug in pycparser failing to parse that statement, I'll look into
> fixing it.
>
> > These should all be simple changes. Adding fortran support however
> > will not be as simple, because the code formatting framework is
> > quite low level and close to the structure of C/C++ code, so that's
> > a completely different project. Probably easier to generate C and
> > call from fortran then :)
>
> We don't have any plans to support Fortran at the moment, but I can
> see how it would be an issue as the FFC code generation is modeled
> quite closely around C/C++.

We've tried to isolate everything C++-specific to cpp.py and
codesnippets.py and the ambition is to make it possible to support
Fortran.

-- 
Anders