[petsc-dev] multiple dispatch code currently in PETSc
Jed Brown
jedbrown at mcs.anl.gov
Tue Jan 15 14:55:57 CST 2013
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130115/3dc21b2a/attachment.html>
More information about the petsc-dev
mailing list