[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

Jed Brown jedbrown at mcs.anl.gov
Wed Mar 6 00:10:47 CST 2013

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 SNESDestroy_VI(SNES);
> PETSC_EXTERN PetscErrorCode SNESView_VI(SNES,PetscViewer);
> PETSC_EXTERN PetscErrorCode SNESSetFromOptions_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>

More information about the petsc-dev mailing list