VecLoadIntoVector and double dispatch

Barry Smith bsmith at
Thu Dec 3 15:09:03 CST 2009

On Dec 3, 2009, at 2:29 PM, Jed Brown wrote:

> Thanks for the explanation.
> On Thu, 3 Dec 2009 13:48:21 -0600, Barry Smith <bsmith at>  
> wrote:
>>    This is wrong. What about a binary viewer method for the PETSc Vec
>> class implemented in SAMRAI? This definitely cannot rely on
>> VecGetArray() and belongs with the Vec class not the viewer classes
>> (which know nothing about SAMRAI even existing.
> I don't know what is in SAMRAI's Vec, but how about my HDF5 viewer  
> that
> encodes information about the DM?  The Vec doesn't know anything about
> my viewer existing.

    But then your viewer must know about DM? That means that your  
viewer knows about the internal structure of the vector?

    I think this is very wrong. The viewer object is a lower level  
object, it doesn't even know about linear algebra or vectors, nothing.  
It should only expose a bunch of methods that the "higher level"  
objects use. No viewer class show know about any Vec class or even the  
existence of the Vec abstract class, but Vec classes can know about  
the abstract Viewer class and even specific viewer classes.

> Once we have more than one implementation of Viewer
> and more than one of Vec, no asymmetric solution can be perfect.  I  
> can
> live with static dispatch or other hacks for now.

    I agree that no asymmetric solution is perfect, but I think it is  
very useful to have a hierarchy of classes that "know" about other  
classes; so the Vec class knows about Viewer classes but the Viewer  
classes do not know about Vec classes. Otherwise you get nasty "loops  
of knowledge" that are difficult to unwind.


> Jed

More information about the petsc-dev mailing list