[petsc-dev] declaring argument as const basic type in PETSc

Chetan Jhurani chetan.jhurani at gmail.com
Wed Aug 17 18:27:35 CDT 2011


> From: Barry Smith
> 
> On Aug 17, 2011, at 2:50 PM, Chetan Jhurani wrote:
> 
> > I never meant to say that one must put const ints in the
> > declaration.
> 
>    Our problem is that because one compiler warns if the const is not listed in both prototype and
> definition we must put it in both (to avoid tons of warning messages that people installing PETSc
> should not see) we MUST put them in the declaration. Which we wanted to avoid since it is anti-
> encapsulation.  So for now, they are forbidden in all PETSc code even though yes they can be useful in
> implementations.

I understand.  One has to take care of many platforms and compilers
that all behave differently.

Anyway, after this discussion I could realize why I have no problem with
code that has const ints in declaration and definition and why it doesn't
break encapsulation (for me).

The philosophy is that -- and I'm not telling this to convert anyone to
my philosophy or to use my definition of encapsulation :-) -- just exposing
inner details is not an encapsulation problem.  Rather, if the exposure
allows the interface user to rely on it and suffer compatibility problems
if the inner details change, only then is it an encapsulation problem (for
me).

In the ongoing example, the user sees const int and can assume that
function will not change the int.  If this behavior changes, say
using a const_cast, or not having the const int in function definition,
then it cannot affect the caller.  Inner details are exposed, but
the caller cannot use the extra details to have any choice in a
decision!  So nothing will break due to this exposure and no new
dependency is created due to it.

"There is only one thing a philosopher can be relied upon to do,
and that is to contradict other philosophers." -- William James

;)

Chetan





More information about the petsc-dev mailing list