[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