[petsc-dev] Preprocessor hell: #define VecType

[Matthew Knepley]

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>