[petsc-dev] Reminder: *every* symbol with extern linkage *must* be namespaced

Jed Brown jedbrown at mcs.anl.gov
Sat Mar 17 13:03:11 CDT 2012


On Sat, Mar 17, 2012 at 12:43, Mark F. Adams <mark.adams at columbia.edu>wrote:

> I am looking for prescriptions.  Several of my problems are local
> functions, I guess I can make these static (I assume this works for
> functions).  I made some attempt to name space some of these (
> gamg_setup_events) and others are tools that need to be global (
> createSimpleGraph)  -- how should I fix these?  PetscCreateSimpleGraph?
>

If it doesn't have a man page, it's not a public interface, so don't let it
grow outside of its current use environment. If it's in the same file, just
make it static. If it needs to be shared between multiple implementation
files, use the namespace you are working under,
e.g. PCGAMGCreateSimpleGraph() or PCGAMGCreateSimpleGraph_Private() to make
it more explicit that this is an internal interface.

I don't understand why you have this gamg_setup_events. These event names
are anything but intuitive in the sense that they don't stand alone and is
denormalized (which makes it non-grepable). I also don't think it makes
sense for GAMG to have its own classid since it's not a new PetscObject. I
suggest registering with

PetscLogEventRegister("PCGAMGCreateProl", PC_CLASSID, &PC_GAMGCreateProl);

and similarly for other events

PCGAMGCreateProl
PCGAMGGraph
PCGAMGGeoGrowSupp
PCGAMGGeoTriangle
PCGAMGPartLevel

In most cases, the event names should approximately (subject to length
constraints) match the routines that implement those events.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120317/be887f69/attachment.html>


More information about the petsc-dev mailing list