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

[Matthew Knepley]

On Sat, Mar 17, 2012 at 12:43 PM, 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?
>

1) Static whenever possible. I did this for most of the TetGen internals

2) Petsc for now, which will prevent clashes

3) Best would be a real Petsc component to house those functions. I want to
make a meshing component, but
    I am holding off until a) it is necessary, and b) I have time.

   Matt


> On Mar 17, 2012, at 12:01 PM, Jed Brown wrote:
>
> On Sat, Mar 17, 2012 at 10:49, Shri <abhyshr at mcs.anl.gov> wrote:
>
>> I don't know namespacing but looks like its a C++ declaration that can be
>> simulated in C either using prefixes or by using a struct.
>> http://ejrh.wordpress.com/2012/01/24/namespaces-in-c/ .
>> What's the prefered PETSc way of namespacing in C? Use the prefix 'Petsc'?
>>
>
> Yes, use prefixes for all symbols with extern linkage. (Whichever prefix
> is appropriate for the class you are working with.)
>
> If you have symbols that go togother, and especially if it might make
> sense to have multiple instances, it makes sense to put them together in a
> struct. There may still be a global instance of the struct (which must
> itself be namespaced), but the members of the struct no longer need their
> own namespace because they are not symbols (in the linker sense).
>
> Any time you create a symbol with extern linkage, you are declaring that
> nobody in the universe (defined by all code that might ever be linked into
> an application that somehow calls PETSc) will ever choose that name for
> themselves. PETSc already has (in my opinion) claimed more than its share
> in user-visible namespace (e.g. Vec and Mat), but changing that is
> obnoxious for users so it has been postponed indefinitely. There is no
> excuse, however, for not namespacing new symbols or symbols that are not
> public (intended for the user to interact with).
>
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120317/4f833a5e/attachment.html>