[petsc-dev] declaring argument as const basic type in PETSc
Dmitry Karpeev
karpeev at mcs.anl.gov
Wed Aug 17 13:37:32 CDT 2011
Okay. By "typo" I meant that I never intended to have a "const
PetscInt" argument.
It just got contaminated from the nearby "const PetscInt *".
I'm not sure what meaning "const PetscInt" would have, since C has
pass-by-value
semantics, but I'm not sure whether some C-subtlety might be at play here.
On Wed, Aug 17, 2011 at 10:34 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> On Aug 17, 2011, at 1:31 PM, Dmitry Karpeev wrote:
>
>> That's just a typo on my part.
>> I'm rewriting the whole SA ball of wax, but I can push a quicker fix
>> for this too,
>
> What do you mean typo? I fixed the repository so that the declaration and the prototype match. You don't need to do anything.
>
> But my question remains, should we const declare function arguments?
>
> barry
>
>> but, unfortunately, I won't be able to do that untill next Monday.
>>
>>
>> Dmitry.
>>
>> On Wed, Aug 17, 2011 at 10:09 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>>
>>> Some declarations of the form
>>>
>>> extern PetscErrorCode SAAddData(SA arr, const PetscInt len, const PetscInt *ia, const PetscScalar *wa, const PetscInt *ja);
>>>
>>> have crept into PETSc. const PetscInt len
>>>
>>> Do we want to have such beasties? What purpose do they serve?
>>>
>>> My understanding is that it is contaminating the entire code (because of the extern PetscErrorCode SAAddData(SA arr, const PetscInt len, const PetscInt *ia, const PetscScalar *wa, const PetscInt *ja); with the knowledge that internally the subroutine never changes the value of the stack variable function which is the opposite of encapsulation. What am I missing? Is this just stupid C syntax, is there a better way?
>>>
>>> Thanks
>>>
>>> Barry
>>>
>>>
>
>
More information about the petsc-dev
mailing list