<br><br><div class="gmail_quote">On Tue, Jan 15, 2013 at 3:20 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@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 dir="ltr"><div class="gmail_extra"><div class="im">On Tue, Jan 15, 2013 at 3:14 PM, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br>

<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is, by the way, the 'type' field in the header, which the docs say should no longer be used, and which is typically set to 0 or -1 in calls to PetscHeaderCreate.  So, barring some subtle backward-compatibility issue this can be reused to hold the typeid, which is computed or looked up on each PetscObjectChangeTypeName()?</blockquote>


</div><br></div>The usual way to do this would be to make the classid field be either a pointer or an index into a global petsc_classes data structure. I recently set up that infrastructure for Fortran pointers, but that class object could be used for multiple dispatch as well.</div>

</div></blockquote><div>I'll try to take a look at this over the weekend.</div><div>Dmitry. </div></div><br><br><div>-----------------------</div>