[petsc-dev] Preprocessor hell: #define VecType

[Barry Smith]

On Sep 28, 2012, at 3:01 PM, Matthew Knepley <knepley at gmail.com> wrote:

> On Fri, Sep 28, 2012 at 3:17 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
> 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:
> 
> Unfortunately no, this does not work, or we would have done this.

    The problem is we/people may want to "build" XXXType values on the fly with string operations like strcpy, strcat etc. You cannot do that into a const char*, thus we/people would have to declare the place they build things as char* instead of XXXType and that is "unnatural".  Keep digging; we all agree with you that it would be good to get rid of the #define. 

    I view this problem as a slight "flaw" in typedef, but perhaps C typedef has a solution?

   Barry

> 
>    Matt
>  
> $>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
> 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener