On Wed, Jun 1, 2011 at 3:48 AM, Jed Brown <jed at 59a2.org> wrote: > On Wed, Jun 1, 2011 at 04:56, Matthew Knepley <knepley at gmail.com> wrote: > >> I did not want to downcast because PetscPow() works for (Scalar, Int) and >> (Scalar, Real) so automatically casting to (int) is not right. > > > 1. There is no PetscPow() :-) > > 2. In C, PetscPowScalar *always* has arguments (PetscScalar, PetscScalar), > *not* (PetscScalar,PetscReal), (PetscScalar, int), or other variants. The > fact that it "works" with other combinations is only because of C's > automatic promotion rules. C++ has different promotion rules and overloads > the name for (PetscScalar, int). >
Yes, C was not producing a problem. > This still isn't (PetscScalar, PetscInt). Indeed, if PetscInt is int64_t, > then PetscPowScalar(some_scalar, some_int) fails. That is the problem you > fixed by introducing PowInt. But PowInt is always defined to be int, either > by explicit typedef (with PETC_USE_64BIT_INDICES) or indirectly (because > PetscInt was already typedef'd to int). So "typedef int PowInt" will always > be equivalent to what you have. > BUT that cast is explicit so the user knows. I do not see a way to do it implicitly. If they really wanted a Scalar, it would get cast to an int. Alternatively, If they really wanted and int, it would get cast to a Scalar. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110601/0e19a5e9/attachment.html>