[petsc-dev] Forward declarations of types?

[Jed Brown]

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.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130215/f200a08f/attachment.html>