[petsc-dev] Nonblocking consensus and alternative "freespace" interface

Barry Smith bsmith at mcs.anl.gov
Mon Jan 7 17:42:31 CST 2013


On Jan 7, 2013, at 5:28 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Mon, Jan 7, 2013 at 3:29 PM, Matthew Knepley <knepley at gmail.com> wrote:
> The PetscOptions and PetscInfo functions are examples where we used _Private to
> indicate a lower level interface, rather than one that was truly file scope. I guess we
> need two different specifiers.
> 
> Most of these are in matimpl.h and vecimpl.h. They should perhaps be called _Internal since they are shared inside PETSc, but not public. We should also change them from PETSC_EXTERN so that we can set visibility=hidden to prevent users from calling them through shared libraries. ;-)

   I have no problem making them _Internal instead of _Private if that is clearer. And making them not PETSC_EXTERN

> 
> I don't have a problem with non-namespaced functions at file local scope, 

    I do have a problem with them, because I read code I haven't seen before (that Jed or someone who copied Jed wrote) that looks like 

     PetscCoolClassAFunction(PetscSomething, ….) {
       …..
       PetscStrcpy().
       SomenameofSomething().
       ISCreate…()
     }

     and I don't know if SomenameofSomething is private to this file or from some other package. (note many other packages don't namespace so I cannot tell if it is some other package). This interrupts the flow of the understanding of the code so I need to restart (having to jump to somewhere else in the file to see if SomenameofSomething() is in the file and a local utility. I would prefer

     PetscCoolClassAFunction(PetscSomething, ….) {
       …..
       PetscStrcpy().
       PetscCoolClassSomething_Static().
       ISCreate…()
     }

now I immediately know it is a utility function associated with the PetscCoolClass and it is also static (so private to the file). I can keep on reading.

Just making up random names (no mater how local) is not good literate programming :-)

So we are proposing utility functions in PETSc NOT for external users are PetscClassFunction_Internal() and for static functions in a file are PetscClassFunction_Static()?


  Barry

Yes I realize the static is redundant with the declaration of the function but I am not reading the declaration I am reading the use and don't want to interupt the flow by jumping around.




 

> they just have to be renamed if they are ever referenced from elsewhere.




More information about the petsc-dev mailing list