[petsc-dev] Preprocessor hell: #define VecType

[Karl Rupp]

> High five, Karl.

High five! :-)


> On Sep 30, 2012 6:46 AM, "Karl Rupp" <rupp at mcs.anl.gov
> <mailto: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
>
>