<p>High five, Karl.</p>
<div class="gmail_quote">On Sep 30, 2012 6:46 AM, "Karl Rupp" <<a href="mailto:rupp@mcs.anl.gov">rupp@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
>>> ^^^ Note that this const is superfluous.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why is it superfluous?  Isn't the second argument type const char* const this way?<br>
<br>
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.<br>

</blockquote>
<br>
   Which clearly I don't :-(<br>
<br>
    So do we just go with typedef const char* VecType   and then all signatures are  VecType?<br>
</blockquote>
<br>
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.<br>
<br>
Example:<br>
  #define VecType char*<br>
  int Set(const VecType)<br>
expands to<br>
  int Set(const char*)<br>
<br>
However, with<br>
  typedef const char* VecType<br>
  int Set(const VecType)<br>
there is no immediate string replacement, i.e. it is NOT the same as<br>
  int Set(const const char*)<br>
with the compiler ignoring one of the const keywords. Instead, denoting the precedence using brackets, the type passed to the Set() is<br>
  const {const char*}<br>
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<br>
  Set(VecType);<br>
  Get(VecType*);<br>
which is pretty much the standard prototype for any pair of Getter/Setter and also the way arguments of type PetscInt are handled.<br>
<br>
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 :-)<br>

<br>
Best regards,<br>
Karli<br>
<br>
<br>
</blockquote></div>