[petsc-dev] Arguments that are logically void**

Kai Germaschewski kai.germaschewski at unh.edu
Mon Jun 6 13:34:02 CDT 2011

Wouldn't it make sense to  have DMDAVecGetArray[23]d() and have the argument
be PetscScalar ***, and PetscScalar ****, respectively? That would actually
check that one passes in a reference to the right type, making it both safe
and avoid the need for casting? That's also more in line with, e.g.,

I'm not sure where else void ** is used, and whether similar solutions would
apply. In general, I agree with Jed that I'd rather not have the explicit
cast in the user code.


On Mon, Jun 6, 2011 at 2:20 PM, Jed Brown <jed at 59a2.org> wrote:

> On Mon, Jun 6, 2011 at 20:00, Barry Smith <bsmith at mcs.anl.gov> wrote:
>> So is the only benefit that one does not need the extra characters
>> (void**) in front of the argument?
> Yes.
> Rationale.
> The use of a formal parameter attribute_val or type void* (rather than
> void**) avoids the messy type casting that would be needed if the attribute
> value is declared with a type other than void*. ( End of rationale.)
>>   Doesn't seem like much of a benefit? At this point I think doing it
>> either way is fine but if we are inconsistent we should fix some of them to
>> be consistent. I am leaning to vote for the (void**) approach; it is clearer
>> when one looks at code.
> I think the cast is ugly if it appears in places that should not be
> "scary". For example, I think DMDAVecGetArray(da,X,&x) is significantly
> nicer than DMDAVecGetArray(da,X,(void**)&x).
> Needing an explicit cast makes the reader think about the safety of the
> cast. This is a good thing for calls that should look a bit scary.

Kai Germaschewski
Assistant Professor, Dept of Physics / Space Science Center
University of New Hampshire, Durham, NH 03824
office: Morse Hall 245E
phone:  +1-603-862-2912
fax: +1-603-862-2771
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110606/3e19a807/attachment.html>

More information about the petsc-dev mailing list