On Feb 7, 2013, at 5:40 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Thu, Feb 7, 2013 at 5:21 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > > 1) Get rid of all function-like CPP things > > > > Right now we can get rid of any CPP macro functions that can be > > trivially converted to C functions. The ones we cannot get rid of are ones > > that take "types" or block sizes as arguments. (these are used as code > > generation macros; generating a chunk of C code for each type). > > > > We should work on eliminating those first. This is a good test of how > > usable the code generation would be. > > The problem is that we cannot do the code generation properly until we've > removed all the CPP code first. So it seems to me that these should be > eliminated last (since they are vital to working PETSc). But I could be > wrong, Karl? > > Huh? There are still plenty of CPP macro functions that could be inline > functions. Yes and those need to be fixed. > What are you going to do with stuff like PetscTryMethod and > PetscOptionsBegin? Those _seriously_ change the behavior of the code, in ways > that cannot be expressed in C (without just expanding the entire macro, but > that's just replacing CPP with our own replacement macro language). These are in the category of those that CANNOT be trivially converted to C functions. They are the tough nuts to crack. We need to categorize them and see what makes sense to do with them. Barry
