[petsc-dev] Preprocessor hell: #define VecType

[Karl Rupp]

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