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


   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


Reply via email to