On Tue, Jan 15, 2013 at 2:55 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Tue, Jan 15, 2013 at 2:51 PM, Dmitry Karpeev <karpeev at mcs.anl.gov>wrote: > >> I think passing PetscObject is natural here, in which case using >>> obj->type_id instead of obj->type_name can be done later. But on that >>> front, yes, I think making integers for all registered type_names would be >>> good. Among other things, it would make the PetscObjectTypeCompares fast, >>> although I think those places should eventually be refactored. >>> >> Some of the arguments aren't PetscObjects (e.g., PODs). >> Each dispatcher (e.g., MatMultMult) can have static integer typeids for >> all of its arguments that are registered >> or retrieved only on the first invocation and reused from then on. >> > > Are you talking hypothetically? Because what's in there now is just > dispatch based on the types of PetscObjects. > Right. I guess the non-PetscObject arguments don't vary between implementations, so we can stick to PetscObjects. > > Note that generic PetscObject routines would have to ensure that type ids > never collided, even if the objects were of different classes. If we pass > the object, that's easy to verify. The current PetscOpFListFind() will fail > at distinguishing an AOBASIC from a SNESLINESEARCHBASIC or a PETSCSFBASIC. > Passing PetscObject is safer in this regard. > Right. Typeids would have to be assigned to (classid,type_name) pairs, since type_names are only unique within a class. I'm on board with passing PetscObjects for argument matching (and squeezing out the non-PetscObject args). 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()? Dmitry. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130115/d372f427/attachment.html>