[petsc-dev] Preprocessor hell: #define VecType

[Aron Ahmadia]

^5 and +1

On Sun, Sep 30, 2012 at 6:21 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
>> 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
>>
>>
>

-- 

------------------------------
This message and its contents, including attachments are intended solely 
for the original recipient. If you are not the intended recipient or have 
received this message in error, please notify me immediately and delete 
this message from your computer system. Any unauthorized use or 
distribution is prohibited. Please consider the environment before printing 
this email.