On Tue, Mar 5, 2013 at 11:57 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> This is very nice, much better than before, no confusing macros and > complicated #if conditions, simpler for the users to understand also. > > Does this mean we shouldn't/don't need to/should continue to mark > functions used in a single file as static? > If we use --with-visibility, unadorned functions behave like PETSC_INTERN except that their names will be mangled for clanguage=C++. (The symbols aren't visible outside the library so that doesn't matter, except to language purists and possibly C++ exception propagation.) I would still prefer to use 'static' whenever possible because it makes it easier to determine how much code could depend on that function. > I found a few problems so far > > 0) Do these really need PETSC_EXTERN? Note that they are not declared > PETSC_EXTERN when defined, only in snesimpl.h > > PETSC_EXTERN PetscErrorCode SNESReset_VI(SNES); > PETSC_EXTERN PetscErrorCode SNESDestroy_VI(SNES); > PETSC_EXTERN PetscErrorCode SNESView_VI(SNES,PetscViewer); > PETSC_EXTERN PetscErrorCode SNESSetFromOptions_VI(SNES); > PETSC_EXTERN PetscErrorCode SNESSetUp_VI(SNES); > PETSC_EXTERN_TYPEDEF typedef PetscErrorCode > (*SNESVIComputeVariableBoundsFunction)(SNES,Vec,Vec); > PETSC_EXTERN PetscErrorCode > SNESVISetComputeVariableBounds_VI(SNES,SNESVIComputeVariableBoundsFunction); > PETSC_EXTERN PetscErrorCode SNESVISetVariableBounds_VI(SNES,Vec,Vec); > PETSC_EXTERN PetscErrorCode > SNESDefaultConverged_VI(SNES,PetscInt,PetscReal,PetscReal,PetscReal,SNESConvergedReason*,void*); > They can all become PETSC_INTERN unless we have reason to support plugin authors or petscts calling those directly instead of using an interface. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130306/9b9f0e38/attachment.html>
