On Thu, Feb 7, 2013 at 1:23 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > Since this is only BLAS-related, we should move all the BLAS-calls to a > separate package with the sole purpose of providing a unified (binary) > interface for the PETSc core. This will allow us to keep the PETSc core > clean and put all the ugly stuff in that 'unification sublibrary'. This > should eliminate any BLAS-related CPP usage from the PETSc core. > I agree with this. This beastie may as well expose a C interface and have proper error handling while we're at it. If it had a SetErrorHandler(), we could wire it up to call back into PetscError, in which case we'd be able to call it like a normal C function. > > >> Sometime I will send a detailed email explaining why I wish to > totally eradicate CPP. > > > > This is a noble goal with my full support, yet very hard to achieve. How > do we want to tackle CHKERRQ for example? > > This is actually an easy one. Once we have a pure C code that can be > completely represented in a full AST, then it is trivial to have a "pretty > printer" that automatically adds into the code the equivalent of __FUNC__, > PetscFunctionBegin/End, CHKERRQ(), PetscStackCall() etc BEFORE passing the > code into the compiler to be compiled down to object code. > > Thus PETSc will actually ultimately become simpler C code without all > the additional stuff we have added for error checking/handling etc. Happy > days :-) I think this would be bad. It creates lots of build system complexity and will make error messages trace through the generated code that we never see explicitly. I don't think you can do this sort of source modification without the abstraction being leaky and seemingly magical. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130207/45666483/attachment.html>
