<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 5:21 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">> >   1) Get rid of all function-like CPP things<br>
><br>
>     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).<br>

><br>
> We should work on eliminating those first. This is a good test of how usable the code generation would be.<br>
<br>
</div>  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?</blockquote>
</div><br>Huh? There are still plenty of CPP macro functions that could be inline functions. 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).</div>
</div>