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

[Barry Smith]

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."


   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