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 _______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
