[petsc-dev] Arguments that are logically void**
Barry Smith
bsmith at mcs.anl.gov
Mon Jun 6 13:00:34 CDT 2011
So is the only benefit that one does not need the extra characters (void**) in front of the argument?
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.
Barry
On Jun 6, 2011, at 6:40 AM, Jed Brown wrote:
> There are a few places in PETSc where arguments that are logically void** are implemented as void*. This removes the need for the user to provide an explicit cast, and is backward compatible. MPI adopted this convention between version 1.0 and 1.1. For example,
>
> int MPI_Attr_get(MPI_Comm comm, int keyval,void **attribute_val, int *flag ) /* MPI-1.0 */
>
> int MPI_Attr_get(MPI_Comm comm, int keyval,void *attribute_val, int *flag ) /* MPI-1.1 and later */
>
>
> Inside the implementation, the actual assignment would look something like
>
> *(void**)attribute_val = comm->attr_table[keyval];
>
>
> Should we adopt this uniformly? The benefit is that the user doesn't need to *always* cast to (void**) every time they call the function.
>
> The downside is that the function signature does not make it obvious that the user should pass the address of their pointer. On the other hand, C pass-by-value semantics guarantee that the function couldn't do anything like what it says if you didn't pass in the address of your pointer.
>
>
> Note that this change cannot be made for (void(**)(void)) function arguments because function pointers are not castable to non-function pointers (as per the C standard, though it works on many platforms).
More information about the petsc-dev
mailing list