[petsc-dev] How to enforce private data/methods in PETSc?

[Junchao Zhang]

See this example, after multiple casts, the code directly accesses
VecScatter_MPI_General's members, with an assumption that from->n is the
total number of receive processors. When I separate intranode / internode
communications, I have to maintain this assumption.

385: *PetscErrorCode
<http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/PetscErrorCode.html#PetscErrorCode>
MatMatMultNumeric_MPIDense(Mat
<http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat>
A,Mat <http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat>
B,Mat <http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat>
C)*386: {

389:   Mat_MPIAIJ             *aij = (Mat_MPIAIJ*) A->data;
393:   VecScatter
<http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Vec/VecScatter.html#VecScatter>
            ctx   = aij->Mvctx;394:   VecScatter_MPI_General *from =
(VecScatter_MPI_General*) ctx->fromdata;395:   VecScatter_MPI_General
*to   = (VecScatter_MPI_General*) ctx->todata;
411:   PetscMalloc4
<http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/PetscMalloc4.html#PetscMalloc4>(B->cmap->N*from->starts[from->n],&contents->rvalues,412:

B->cmap->N*to->starts[to->n],&contents->svalues,413:
    from->n,&contents->rwaits,414:
to->n,&contents->swaits);


--Junchao Zhang


On Fri, Aug 10, 2018 at 10:33 PM Matthew Knepley <knepley at gmail.com> wrote:

> On Fri, Aug 10, 2018 at 11:29 PM Junchao Zhang <jczhang at mcs.anl.gov>
> wrote:
>
>> It seems we do not have naming conventions for private members.
>>
>
> I am not sure I understand. There are no public members. For private
> functions, we do have
> a naming convention, but it is newly created, so many of the existing
> functions break the rules.
>
>    Matt
>
>
>> --Junchao Zhang
>>
>>
>> On Fri, Aug 10, 2018 at 9:43 PM Matthew Knepley <knepley at gmail.com>
>> wrote:
>>
>>> On Fri, Aug 10, 2018 at 5:43 PM Junchao Zhang <jczhang at mcs.anl.gov>
>>> wrote:
>>>
>>>>  I met several bugs that remind me to raise this question. In PETSc,
>>>> object of type A can arbitrarily access object of type B's data. But
>>>> designer of B may later change the meaning of its data (and of course,
>>>> update B's interfaces, which are usually local to few files). The designer
>>>> may think the job is done, but actually it is not.  He/she has to grep the
>>>> code to know where its data members are accessed (that is relatively easy
>>>> to get) and what is the contract, for example, is an array assumed to be
>>>> sorted (that is hard to know).  With C++, one can use private to minimize
>>>> data exposure.
>>>>
>>>
>>> This just has to be coding discipline. People should not be accessing
>>> private members.
>>>
>>>    Matt
>>>
>>>
>>>> --Junchao Zhang
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
>>>
>>
>
> --
> 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
>
> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180810/70bea7d7/attachment.html>