[petsc-dev] Preprocessor hell: #define VecType

[Karl Rupp]

Hi,

 >       The reason we use a #define instead of typedef is because of
> (...)
>
> 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.

Ok, I see. Let me be a bit persistent then and hunt for occurrences of 
'VecType' without 'const':

$> grep -r "VecType" *.h | grep -v "const VecType"
petscvec.h:.seealso:  VecCreate(), VecType, VecSetType()
petscvec.h:    VecType - String with the name of a PETSc vector or the 
creation function
petscvec.h:#define VecType char*


Alright, so
  typedef const char * VecType;
should work here. Let's check for MatType:

$>grep -r "MatType" *.h | grep -v "const MatType"
petscmat.h:.seealso:  MatCreate(), MatType, MatSetType()
petscmat.h:    MatType - String with the name of a PETSc matrix or the 
creation function
petscmat.h:#define MatType char*
petscmat.h:.seealso: MatGetFactor(), Mat, MatSetType(), MatType
petscmat.h:    Notes: MATMFFD is a specific MatType which uses the 
MatMFFD data structure


So
  typedef const char * MatType;
should also be fine here as well. Repeating the game for all PETSc-types 
with the following bash-beast (i.e. repeat the procedure above for every 
#define XYZType char*):
for t in `grep -hr "Type char" *.h | sed '/^#define */!d; s///;' | sed 
'/ char\*/!d; s///;'` ; do   grep -r "${t}" *.h | grep -v "const ${t}"; done

one finds only a single function which is not using a 'const' in front 
of any *Type defined via the preprocessor:
PETSC_EXTERN PetscErrorCode MatColoringRegister(const char[],const 
char[],const char[],PetscErrorCode(*)(Mat,MatColoringType,ISColoring *));
Now, assuming that 'const' was simply forgotten here, what about 
typedef-ing everything to 'const char *' then? It shouldn't be too much 
of a painful day...


> 2)   Having Vec but PetscVecType would be terribly inconsistent mess.   Better to switch everything in one painful day.

In the context of what Matt said initially (of which I wasn't aware and 
I wouldn't have expected a general PETSc-type to be defined via a 
preprocessor define), it is indeed inconsistent.

Best regards,
Karli