On Sep 28, 2012 2:13 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote: > > > Karl, > > 1) > > The reason we use a #define instead of typedef is because of > > ch-uni/include -I/usr/X11R6/include -I/opt/local/include -I/Users/barrysmith/Src/petsc-dev/include/mpiuni -o CMakeFiles/petsc.dir/src/vec/vec/impls/nest/vecnest.c.o -c /Users/barrysmith/Src/petsc-dev/src/vec/vec/impls/nest/vecnest.c > /Users/barrysmith/Src/petsc-dev/src/vec/vec/impls/shared/shvec.c:230:24: warning: passing 'const char [7]' to parameter of type 'VecType' (aka 'char *') discards qualifiers [-Wincompatible-pointer-types] > ierr = VecSetType(*v,VECSHARED);CHKERRQ(ierr); > ^~~~~~~~~ > /Users/barrysmith/Src/petsc-dev/include/petscvec.h:101:24: note: expanded from macro 'VECSHARED' > #define VECSHARED "shared" > ^~~~~~~~ > /Users/barrysmith/Src/petsc-dev/include/petscvec.h:308:58: note: passing argument to parameter here > PETSC_EXTERN PetscErrorCode VecSetType(Vec, const VecType); > ^ > "/Applications/CMake 2.8-8.app/Contents/bin/cmake" -E cmake_progress_report /Users/barrysmith/Src/petsc-dev/arch-uni/CMakeFiles > > > We really want to be able to const the beast in many places and I couldn't get it to work with typedefs in a way natural for users. If you can come up with a clean natural way to handle the const we can switch. > > 2) Having Vec but PetscVecType would be terribly inconsistent mess. Better to switch everything in one painful day.
I don't agree. Its only loosely connected, there is no way to mistake what we mean, and it sets up the later change. Matt > > > Barry > > > > > > On Sep 28, 2012, at 12:33 PM, "Chetan Jhurani" <chetan.jhurani at gmail.com> wrote: > > >> -----Original Message----- > >> From: petsc-dev-bounces at mcs.anl.gov [mailto: petsc-dev-bounces at mcs.anl.gov] On Behalf Of Karl Rupp > >> Sent: Friday, September 28, 2012 9:59 AM > >> To: For users of the development version of PETSc > >> Subject: Re: [petsc-dev] Preprocessor hell: #define VecType > >> > >> Hi, > >> > >>> You are missing the fact that all PetscObjects have an implementation > >>> type and it is a string, and there is > >>> one of these #defines for every class. > >> > >> Ok, thanks for shedding light on that. > >> > >>> However, I would support namespacing all these Types since they are not > >>> in heavy use, e.g. PetscVecType, PetscMatType. > >> > >> I assume that any compiler errors would be a LOT clearer if VecType were > >> at least a typedef instead of a brutal preprocessor-define. Without > > > > There won't be any error in compiling > > > > template <typename MatrixType, typename VecType> > > > > if VecType were a typedef. > > > > Chetan > > > > > >> having checked the following, > >> #define VecType PetscVecType > >> typedef char* PetscVecType; > >> may already improve the situation substantially. Removing any > >> preprocessor activity on the string/type 'VecType' would be the cleaner > >> approach, though... > >> > >> Best regards, > >> Karli > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120928/c1632e96/attachment.html>
