On Feb 7, 2013, at 9:58 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Thu, Feb 7, 2013 at 7:20 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > You are too hung up on the "generating" that code. The issue is to have a > "complete" software base that is machine manipulatable, how the tiny bit of > code that is not manipulatable is manage is not central to the discussion. > But note that have non-machine manipulatable in the include directory files > pretty much means that no code will be machine manipulatable. > > We'll always have system stuff and stuff related to other libraries in > headers. True. Minimizing it as much as possible will make the rest of the job easier. > > I think it really matters how those bits of code are managed because that's > something we have to teach the code manipulator about. The reason I am insistent on minimizing CPP is that it is easy to teach a pure C manipulator stuff. It is very difficult (I submit) to teach a CPP + C manipulator much of anything expecially when "nasty" CPP tricks are used. Plus there are good C manipulation tools coming on line, there are no, and never will be, good CPP + C manipulation tools. Barry > That is, if the code you want to manipulate does not use CPP, or you can > teach the manipulator about those bits of CPP (like CHKERRQ), then it's not a > problem to code manipulation. And if you have some "other" system for > PetscOptions (which is an important macro that is used all over the place), > the manipulator still needs to know enough about the semantics of that > construct to not mess it up.
