[petsc-dev] Preprocessor hell: #define VecType

Barry Smith bsmith at mcs.anl.gov
Fri Sep 28 13:13:18 CDT 2012


   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.


  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
> 




More information about the petsc-dev mailing list