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

[Barry Smith]

On Aug 17, 2011, at 3:30 PM, Matthew Knepley wrote:

> On Wed, Aug 17, 2011 at 10:24 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> On Aug 17, 2011, at 3:20 PM, Matthew Knepley wrote:
> 
> > On Wed, Aug 17, 2011 at 10:13 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> > On Aug 17, 2011, at 3:08 PM, Matthew Knepley wrote:
> >
> > > On Wed, Aug 17, 2011 at 10:05 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > >
> > >  Because it exposes a completely implementation detail to the public interface, (unnecessarily at that) So yes it is for philosophical reasons that we must reject this badly designed C standard.
> > >
> > > So you are saying that, according to the standard (Jed will certainly have a reference), that some value parameter
> > > declared as const can be assigned to in the function? If that is so, it is full of crap. Every compiler I have used bombed
> > > on that, and (lacking real authority) during my Google interview they thought this was good practice.
> >
> >   No I am not saying that. Not even close, how could you possibly have gotten that from the sentence "Because it exposes a completely implementation detail to the public interface, (unnecessarily at that) So yes it is for philosophical reasons that we must reject this badly designed C standard."
> >
> > This way. You said it was a "completely implementation detail", from which I supposed that different compilers were allowed
> > to interpret it as they see fit (thats what I thought an implementation detail was). I asked for confirmation on this: "does the
> > standard allow a 'const' parameter to be assigned to?", since I know every compiler I have tried does not allow this. I thought
> > your philosophical reason was that the standard allows a 'const' value declaration, but enforces nothing. Is this wrong?
> 
>  Yes it is wrong.
> 
>   The point is that whether the function changes that value inside itself is completely an implementation detail of the function (not the compiler) and there is no reason to expose that implementation detail to the rest of the world.  It's as stupid as having a construct in the extern prototype saying "there is no variable internal to this function implementation named joe".
> 
> I see. You think the C standards committee was at fault for choosing a bad mechanism to enforce this kind of safety check. Fine.

   Yes, they should have said you put the const in the function and NOT in the extern prototype and no compiler is allowed to bitch if you don't put it in the extern prototype and in fact you are not allowed to put it in the extern prototype.

   Barry

> 
>    Matt
>  
> 
>   Barry
> 
> >
> >    MAtt
> >
> >
> >   Barry
> >
> > >
> > >    Matt
> > >
> > >
> > >   Barry
> > >
> > >
> > > On Aug 17, 2011, at 2:58 PM, Matthew Knepley wrote:
> > >
> > > > On Wed, Aug 17, 2011 at 9:08 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > >
> > > > On Aug 17, 2011, at 2:04 PM, Chetan Jhurani wrote:
> > > >
> > > > >> From: Jed Brown
> > > > >> Sent: Wednesday, August 17, 2011 12:38 PM
> > > > >> To: For users of the development version of PETSc
> > > > >> Subject: Re: [petsc-dev] declaring argument as const basic type in PETSc
> > > > >>
> > > > >> On Wed, Aug 17, 2011 at 11:34, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > > >>> But my question remains, should we const declare function arguments?
> > > > >>
> > > > >> No, the prototype should never use const for stack arguments (pointer to const
> > > > >> is totally different and should be used anywhere that it is correct).
> > > > >>
> > > > >> I don't know any responsible libraries that const-ify value parameters in
> > > > >> prototypes. I think it most commonly arises from ignorance of, or sloppiness
> > > > >> with, the actual semantics of the C language.
> > > > >
> > > > >
> > > >   So by the standard a compiler should never bitch if in the function definition it is declared const but in the extern prototype it is not declared const? (This is an exception to the usual rule that the extern arguments should match the definition arguments?)
> > > >
> > > > Just so I understand, this declaration and definition:
> > > >
> > > > void foo(const int a);
> > > >
> > > > void foo(const int a) {
> > > > }
> > > >
> > > > is legal, and would prevent a developer from accidentally assigning to a, but we are outlawing it. I do not
> > > > see the rationale.
> > > >
> > > >     Matt
> > > >
> > > >    Thanks
> > > >
> > > >  Barry
> > > >
> > > > > It is useful to have const pass-by-value parameters in function
> > > > > definitions.  Not useful in the function declarations or for the
> > > > > caller.
> > > > >
> > > > > This is so that a developer does not assign to a passed-in int
> > > > > unintentionally.  Almost all C and C++ compilers accept it and they
> > > > > error out if one does something like the code below.  An exception
> > > > > is old IRIX compilers that emit a warning on using const pass-by-value
> > > > > and said it is meaningless to use them.  I disagree.
> > > > >
> > > > > void f(const int n, int* j)
> > > > > {
> > > > >    *j = n;
> > > > >    n = 0; // error
> > > > > }
> > > > >
> > > > > Of course it is more useful for preventing bugs in more complex
> > > > > functions.
> > > > >
> > > > > Chetan
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > >
> > >
> > >
> > >
> > > --
> > > 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
> >
> >
> >
> >
> > --
> > 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
> 
> 
> 
> 
> -- 
> 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