[petsc-dev] Preprocessor hell: #define VecType

[Barry Smith]

  I have pushed the change for 
#define XXXType char* to typedef const char* XXXType;   2f1984a65b4f 

Please fix or report any problems to petsc-dev at mcs.anl.gov

Congratulations to Karl for his first removal of undesirable #defines in PETSc :-)

Onward to a CPP free PETSc :-)


   Barry

BTW: the nightly builds are terrible, people are pushing incompletely tested code.




On Sep 30, 2012, at 8:46 AM, Karl Rupp <rupp at mcs.anl.gov> wrote:

> Hi,
> 
> >>> ^^^ Note that this const is superfluous.
>>> Why is it superfluous?  Isn't the second argument type const char* const this way?
>>> 
>>> It's superfluous for the same reason we don't "set" by passing "const PetscInt". The const is irrelevant to the caller. All it means is that the implementation doesn't change the *its* copy (pass by value) and even that isn't type checked with respect to the public declaration. It's just clutter and suggests that the person who wrote it doesn't understand types.
>> 
>>   Which clearly I don't :-(
>> 
>>    So do we just go with typedef const char* VecType   and then all signatures are  VecType?
> 
> yes, Jed is absolutely right on that. The important thing to keep in mind here is that typedef is atomic, i.e. it is not a 'string replacement' as opposed to what the C preprocessor does.
> 
> Example:
>  #define VecType char*
>  int Set(const VecType)
> expands to
>  int Set(const char*)
> 
> However, with
>  typedef const char* VecType
>  int Set(const VecType)
> there is no immediate string replacement, i.e. it is NOT the same as
>  int Set(const const char*)
> with the compiler ignoring one of the const keywords. Instead, denoting the precedence using brackets, the type passed to the Set() is
>  const {const char*}
> which is a const copy to a const char*. Now, as 'const char*' is copied when passed to the function anyways, the first 'const' is superfluous as Jed pointed out. As a consequence, we can simply use
>  Set(VecType);
>  Get(VecType*);
> which is pretty much the standard prototype for any pair of Getter/Setter and also the way arguments of type PetscInt are handled.
> 
> In conclusion, we have not only eliminated the preprocessor magic, we are also able to provide a cleaned-up interface for XYZSetType() and XYZGetType(). Thanks, Barry, for making the decision in favor of a typedef :-)
> 
> Best regards,
> Karli
> 
>