<p dir="ltr"><br>
On Sep 28, 2012 2:13 PM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
><br>
>    Karl,<br>
><br>
> 1)<br>
><br>
>      The reason we use a #define instead of typedef is because of<br>
><br>
> 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<br>

> /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]<br>

>   ierr = VecSetType(*v,VECSHARED);CHKERRQ(ierr);<br>
>                        ^~~~~~~~~<br>
> /Users/barrysmith/Src/petsc-dev/include/petscvec.h:101:24: note: expanded from macro 'VECSHARED'<br>
> #define VECSHARED      "shared"<br>
>                        ^~~~~~~~<br>
> /Users/barrysmith/Src/petsc-dev/include/petscvec.h:308:58: note: passing argument to parameter here<br>
> PETSC_EXTERN PetscErrorCode VecSetType(Vec, const VecType);<br>
>                                                          ^<br>
> "/Applications/CMake 2.8-8.app/Contents/bin/cmake" -E cmake_progress_report /Users/barrysmith/Src/petsc-dev/arch-uni/CMakeFiles<br>
><br>
><br>
> 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.<br>

><br>
> 2)   Having Vec but PetscVecType would be terribly inconsistent mess.   Better to switch everything in one painful day.</p>
<p dir="ltr">I don't agree. Its only loosely connected, there is no way to mistake what we mean, and it sets up the<br>
later change.</p>
<p dir="ltr">   Matt<br>
><br>
><br>
>   Barry<br>
><br>
><br>
><br>
><br>
><br>
> On Sep 28, 2012, at 12:33 PM, "Chetan Jhurani" <<a href="mailto:chetan.jhurani@gmail.com">chetan.jhurani@gmail.com</a>> wrote:<br>
><br>
> >> -----Original Message-----<br>
> >> From: <a href="mailto:petsc-dev-bounces@mcs.anl.gov">petsc-dev-bounces@mcs.anl.gov</a> [mailto:<a href="mailto:petsc-dev-bounces@mcs.anl.gov">petsc-dev-bounces@mcs.anl.gov</a>] On Behalf Of Karl Rupp<br>
> >> Sent: Friday, September 28, 2012 9:59 AM<br>
> >> To: For users of the development version of PETSc<br>
> >> Subject: Re: [petsc-dev] Preprocessor hell: #define VecType<br>
> >><br>
> >> Hi,<br>
> >><br>
> >>> You are missing the fact that all PetscObjects have an implementation<br>
> >>> type and it is a string, and there is<br>
> >>> one of these #defines for every class.<br>
> >><br>
> >> Ok, thanks for shedding light on that.<br>
> >><br>
> >>> However, I would support namespacing all these Types since they are not<br>
> >>> in heavy use, e.g. PetscVecType, PetscMatType.<br>
> >><br>
> >> I assume that any compiler errors would be a LOT clearer if VecType were<br>
> >> at least a typedef instead of a brutal preprocessor-define. Without<br>
> ><br>
> > There won't be any error in compiling<br>
> ><br>
> >       template <typename MatrixType, typename VecType><br>
> ><br>
> > if VecType were a typedef.<br>
> ><br>
> > Chetan<br>
> ><br>
> ><br>
> >> having checked the following,<br>
> >>  #define VecType PetscVecType<br>
> >>  typedef char* PetscVecType;<br>
> >> may already improve the situation substantially. Removing any<br>
> >> preprocessor activity on the string/type 'VecType' would be the cleaner<br>
> >> approach, though...<br>
> >><br>
> >> Best regards,<br>
> >> Karli<br>
> ><br>
><br>
</p>