[petsc-dev] declaring argument as const basic type in PETSc
Barry Smith
bsmith at mcs.anl.gov
Wed Aug 17 21:38:41 CDT 2011
On Aug 17, 2011, at 9:33 PM, Mark F. Adams wrote:
>
> On Aug 17, 2011, at 8:55 PM, Barry Smith wrote:
>
>>
>> On Aug 17, 2011, at 6:18 PM, Mark F. Adams wrote:
>>
>>> Wow, you take an afternoon off and miss 35 emails on petsc-dev....
>>>
>>> I'm a big user of const; I use it whenever I can and never thought that it does not effect the caller for pass by value args, and I'm not sure why anyone would think of it ... as far as "contaminating the entire code" -- that is the purpose of header files, right?
>>
>> Nope, header files are for exposing the public interface; not for exposing irrelevant internal details. In fact, for example, some people consider C++ fundamentally flawed because the details of the class data must be in the public include files and I basically agree with them.
>>
>
> Humm, "details of the class data must be in the public include files" ...
>
> I know C++ does not have an interface-class like some languages, but you can get what you want with coding policy, eg, have base classes with all virtual functions (and no data of course). So there is no explicit language support; a flaw yes, but fatal? Petsc relies on policy a lot -
We have to, because we have no control over the language. If you have control over the language you can and should minimize your dependency on policy and instead enforce "all good things" by fiat :-) That is giving unnecessary freedom to the user does more harm than good.
Barry
> as this discussion thread amply shows.
>
> Mark
>
>> Barry
>>
>>>
>>> I don't understand this fetish but I'm happy to give up my 'const PetscInt' for the pleasure of working in a consistent rigorous environment.
>>>
>>> Mark
>>>
>>> On Aug 17, 2011, at 2:09 PM, Barry Smith 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