High five, Karl. On Sep 30, 2012 6: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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120930/300c2f89/attachment.html>