[petsc-dev] Forward declarations of types?

[Matthew Knepley]

On Fri, Feb 15, 2013 at 5:15 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>   Jed,
>
>    Why petsc-private/${class}types.h ? Why in the private directory. It is
> fine and harmless to include in the public part? plus it allows users to do
> the same trick and not include all the PETSc stuff in much of their code if
> we end up doing it in a systematic way?
>
>    My feeling was that "regular" users could work with a PETSc install
> where petsc-private wasn't even installed and we just install that so that
> people can write their own KSP etc etc.  With this addition now
> petsc-private becomes required.


I think we should just double all include files:

  petscksp.h
  petsckspfwd.h

You don't have to know anything about petsc*fwd.h unless you
want lightweight includes, and there is no way to misinterpret what it is.

   Matt


>
>    Barry
>
> On Feb 15, 2013, at 4:00 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> > On Fri, Feb 15, 2013 at 3:41 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> >   Since google declared calorically that one cannot do this in C and I
> refuse to have
> > #if !defined(PETSCDRAWLGTYPEDEFED)
> > typedef struct xxx
> > #define PETSCDRAWLGTYPEDEFED)
> > #endif
> >
> > Right, this would be tragic. The safe alternative would be to move only
> the type declarations to petsc-private/${class}types.h. Then petscpc.h
> would '#include <petsc-private/dmtypes.h>', but NOT <petscdm.h>. Since
> petscdm.h also includes dmtypes.h, this would not be user-visible (except
> that they would need to include petscdm.h to interact with it, but they
> usually have to include petscdmda.h anyway. (Very few users write truly
> generic DM code.)
> >
> > scattered around I put the typedef of PetscDrawLG into petscys.h then
> small changes were made to the following files
> >
> > M include/petsc-private/drawimpl.h
> > M include/petscdraw.h
> > M include/petscsys.h
> > M src/dm/impls/composite/pack.c
> > M src/dm/impls/da/da1.c
> > M src/dm/impls/da/da2.c
> > M src/dm/impls/da/da3.c
> > M src/dm/impls/da/gr1.c
> > M src/dm/impls/da/gr2.c
> > M src/ksp/ksp/interface/eige.c
> > M src/ksp/ksp/interface/itcreate.c
> > M src/ksp/ksp/interface/itfunc.c
> > M src/ksp/ksp/interface/xmon.c
> > M src/ksp/pc/impls/bjacobi/bjacobi.c
> > M src/ksp/pc/impls/fieldsplit/fieldsplit.c
> > M src/ksp/pc/impls/mg/mg.c
> > M src/ksp/pc/interface/precon.c
> > M src/mat/impls/aij/mpi/mpiaij.c
> > M src/mat/impls/aij/seq/aij.c
> > M src/mat/impls/baij/mpi/mpibaij.c
> > M src/mat/impls/baij/seq/baij.c
> > M src/mat/impls/dense/mpi/mpidense.c
> > M src/mat/impls/dense/seq/dense.c
> > M src/mat/impls/sbaij/mpi/mpisbaij.c
> > M src/mat/impls/sbaij/seq/sbaij.c
> > M src/mat/matfd/fdmatrix.c
> > M src/snes/impls/fas/fas.c
> > M src/snes/interface/snes.c
> > M src/sys/classes/draw/impls/x/ftn-custom/zdrawopenxf.c
> > M src/sys/classes/draw/interface/ftn-custom/zdrawf.c
> > M src/sys/classes/draw/interface/ftn-custom/zdrawregf.c
> > M src/sys/classes/draw/interface/ftn-custom/zdtextf.c
> > M src/sys/classes/draw/interface/ftn-custom/zdtextvf.c
> > M src/sys/classes/draw/interface/ftn-custom/zdtrif.c
> > M src/sys/classes/draw/utils/axis.c
> > M src/sys/classes/draw/utils/axisc.c
> > M src/sys/classes/draw/utils/axisimpl.h
> > M src/sys/classes/draw/utils/dscatter.c
> > M src/sys/classes/draw/utils/ftn-custom/zaxisf.c
> > M src/sys/classes/draw/utils/ftn-custom/zzoomf.c
> > M src/sys/classes/draw/utils/hists.c
> > M src/sys/classes/draw/utils/lg.c
> > M src/sys/classes/draw/utils/lgc.c
> > M src/sys/classes/draw/utils/lgimpl.h
> > M src/sys/classes/viewer/impls/draw/vdraw.h
> > M src/ts/interface/ts.c
> > M src/ts/interface/tseig.c
> > M src/vec/vec/impls/mpi/pdvec.c
> > M src/vec/vec/impls/seq/bvec2.c
> > M src/vec/vec/utils/cmesh.c
> >
> > I'm fine with doing this. Is there a better solution?
> >
> > I can't think of any utility to having PetscDrawLG declared without also
> including petscsys.h, but for something like DM (which most of KSP and
> above does not interact with), I think there is value in putting the
> declaration in dmtypes.h. Should I experiment with that?
> >
> >
> >    Barry
> >
> > On Feb 15, 2013, at 12:38 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> > >
> > >   How does one prevent this problem?
> > >
> > > [ 15%] Building C object
> CMakeFiles/petsc.dir/src/ksp/pc/impls/is/nn/nn.c.o
> > > In file included from
> /Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/bjacobi/bjacobi.c:184:
> > > /Users/barrysmith/Src/petsc-dev/include/petscdraw.h:283: error:
> redefinition of typedef ‘PetscDrawLG’
> > > /Users/barrysmith/Src/petsc-dev/include/petscksp.h:598: error:
> previous declaration of ‘PetscDrawLG’ was here
> > >
> > >
> > > On Feb 15, 2013, at 11:28 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > >
> > >> We currently use recursive includes everywhere, so petscdmda.h
> includes all of petscao.h just so it can declare DMDAGetAO and similar. Of
> course most users of (and implementation files in) DMDA do not reference AO
> so they don't need to know about all the AO functions.
> > >>
> > >> The normal approach to this is to forward-declare the type, so
> instead of
> > >>
> > >> #include <petscao.h> /* includes lots of other stuff */
> > >> PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*);
> > >>
> > >> one would write
> > >>
> > >> typedef struct _p_AO *AO;
> > >> PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*);
> > >>
> > >> in which case all three files in PETSc that actually call AO routines
> would need to include petscao.h. That is arguably a good thing since it
> makes the actual dependencies more explicit, and is recommended by many
> (mostly C++) style guidelines.
> > >>
> > >> Is this something worth considering? I think stuff like petscvec.h
> and petscmat.h ends up pretty much always being needed, but petscdm.h is
> only used by a handful of files in petscksp and above, for example.
> > >>
> > >> It might be nice to get rarely-used stuff like petscdraw.h out of
> petscsys.h.
> > >
> >
> >
>
>


-- 
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/20130215/31239ad5/attachment.html>