February 2013 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Forward declarations of types?
by Jed Brown 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 4:20 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > BTW petscviewer.h included by petscsys.h always includes hdf5.h (when > PETSc installed with hdf5) because of hsize_t and hid_t are in the public > API of PETSc viewer for hdf5. > > We can either have separate petscviewerhdf5.h or we could include just > H5public.h and H5Ipublic.h in petscviewer.h to get these beasties defined. > > I vote for the first but am fine with the second. > I also prefer the first. Very few users of PetscViewer need or want to know anything about HDF5.

1 0

Re: [petsc-dev] Forward declarations of types?
by Matthew Knepley 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 5:15 PM, Barry Smith <bsmith(a)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(a)mcs.anl.gov> wrote: > > > On Fri, Feb 15, 2013 at 3:41 PM, Barry Smith <bsmith(a)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(a)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(a)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

1 0

Re: [petsc-dev] Forward declarations of types?
by Barry Smith 15 Feb '13

15 Feb '13

On Feb 15, 2013, at 4:10 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Fri, Feb 15, 2013 at 3:59 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Ok, I did an implementation with petscdrawtypes.h included by petscdraw.h, petscksp.h and petscsnes.h > > Should it go in petsc-private because it generally doesn't make sense for users to include directly? Or stay out of petsc-private because it's "safe" to include if that's what they want? > > not ideal (I hate having lots of little includes around) but it does keep the PetscDrawLG typedef out of petscys.h > > People ok with me pushing? > > Yup, should I try doing the same with petscdm.h? I see it as perhaps the biggest funny dependency exposed by include-graph.sh. Yes. Note when you do this it decreases the need to have separate petscdmxxx.h files :-) Barry > > > Barry > > Currently only PetscDrawLG is in there, since that is the only one needed but others or all could be put there if desired. > > On Feb 15, 2013, at 3:44 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > On Fri, Feb 15, 2013 at 3:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > > Heh, I thought I remembered that duplicate typedefs were invalid in C, but gcc happily compiled it without a warning. In fact, they _are_ allowed in C11, but not in our old, crusty version of C. > > > > From the looks of it, the C forum never explicitly intended for it to be invalid, but as a consequence of the classification of typedef in C (typedef is classified differently in C++), it would have needed to be explicitly allowed. C11 added that clause. > > > > http://stackoverflow.com/a/8595191/33208 > > > >

1 0

Re: [petsc-dev] Forward declarations of types?
by Barry Smith 15 Feb '13

15 Feb '13

BTW petscviewer.h included by petscsys.h always includes hdf5.h (when PETSc installed with hdf5) because of hsize_t and hid_t are in the public API of PETSc viewer for hdf5. We can either have separate petscviewerhdf5.h or we could include just H5public.h and H5Ipublic.h in petscviewer.h to get these beasties defined. I vote for the first but am fine with the second. Barry On Feb 15, 2013, at 11:28 AM, Jed Brown <jedbrown(a)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.

1 0

Re: [petsc-dev] Forward declarations of types?
by Barry Smith 15 Feb '13

15 Feb '13

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. Barry On Feb 15, 2013, at 4:00 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Fri, Feb 15, 2013 at 3:41 PM, Barry Smith <bsmith(a)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(a)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(a)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. > > > >

1 0

Re: [petsc-dev] Forward declarations of types?
by Jed Brown 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 3:59 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Ok, I did an implementation with petscdrawtypes.h included by > petscdraw.h, petscksp.h and petscsnes.h Should it go in petsc-private because it generally doesn't make sense for users to include directly? Or stay out of petsc-private because it's "safe" to include if that's what they want? > not ideal (I hate having lots of little includes around) but it does > keep the PetscDrawLG typedef out of petscys.h > > People ok with me pushing? > Yup, should I try doing the same with petscdm.h? I see it as perhaps the biggest funny dependency exposed by include-graph.sh. > > Barry > > Currently only PetscDrawLG is in there, since that is the only one needed > but others or all could be put there if desired. > > On Feb 15, 2013, at 3:44 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > On Fri, Feb 15, 2013 at 3:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > > Heh, I thought I remembered that duplicate typedefs were invalid in C, > but gcc happily compiled it without a warning. In fact, they _are_ allowed > in C11, but not in our old, crusty version of C. > > > > From the looks of it, the C forum never explicitly intended for it to be > invalid, but as a consequence of the classification of typedef in C > (typedef is classified differently in C++), it would have needed to be > explicitly allowed. C11 added that clause. > > > > http://stackoverflow.com/a/8595191/33208 > > > >

1 0

Re: [petsc-dev] Forward declarations of types?
by Jed Brown 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 3:41 PM, Barry Smith <bsmith(a)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(a)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(a)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. > > > >

1 0

Re: [petsc-dev] Forward declarations of types?
by Barry Smith 15 Feb '13

15 Feb '13

Ok, I did an implementation with petscdrawtypes.h included by petscdraw.h, petscksp.h and petscsnes.h not ideal (I hate having lots of little includes around) but it does keep the PetscDrawLG typedef out of petscys.h People ok with me pushing? Barry Currently only PetscDrawLG is in there, since that is the only one needed but others or all could be put there if desired. On Feb 15, 2013, at 3:44 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Fri, Feb 15, 2013 at 3:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > Heh, I thought I remembered that duplicate typedefs were invalid in C, but gcc happily compiled it without a warning. In fact, they _are_ allowed in C11, but not in our old, crusty version of C. > > From the looks of it, the C forum never explicitly intended for it to be invalid, but as a consequence of the classification of typedef in C (typedef is classified differently in C++), it would have needed to be explicitly allowed. C11 added that clause. > > http://stackoverflow.com/a/8595191/33208 >

1 0

Re: [petsc-dev] Forward declarations of types?
by Barry Smith 15 Feb '13

15 Feb '13

Boy they added some silly little tiny things in C11 On Feb 15, 2013, at 3:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Fri, Feb 15, 2013 at 12:38 PM, Barry Smith <bsmith(a)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 > > Heh, I thought I remembered that duplicate typedefs were invalid in C, but gcc happily compiled it without a warning. In fact, they _are_ allowed in C11, but not in our old, crusty version of C. > > I guess the reliable way to do this would be to have petsc-private/${pkg}types.h that were included internally by those headers that depend on the types, like petscksp.h. It wouldn't be user-visible, but I'm not sure it's worthwhile.

1 0

Re: [petsc-dev] Forward declarations of types?
by Jed Brown 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 3:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > Heh, I thought I remembered that duplicate typedefs were invalid in C, but > gcc happily compiled it without a warning. In fact, they _are_ allowed in > C11, but not in our old, crusty version of C. > >From the looks of it, the C forum never explicitly intended for it to be invalid, but as a consequence of the classification of typedef in C (typedef is classified differently in C++), it would have needed to be explicitly allowed. C11 added that clause. http://stackoverflow.com/a/8595191/33208

1 0