<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 1:23 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> 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.<br>
</div></blockquote><div><br></div><div style>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
>>    Sometime I will send a detailed email explaining why I wish to totally eradicate CPP.<br>
><br>
> This is a noble goal with my full support, yet very hard to achieve. How do we want to tackle CHKERRQ for example?<br>
<br>
</div>   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.<br>

<br>
   Thus PETSc will actually ultimately become simpler C code without all the additional stuff we have added for error checking/handling etc.  Happy days :-)</blockquote></div><br>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.</div>
</div>