[petsc-dev] marking objects as const in PETSc methods

[Jed Brown]

On Thu, Dec 2, 2010 at 21:41, Barry Smith <bsmith at mcs.anl.gov> wrote:

> I was thinking of something more outside of the usual C syntax. Something
> that the compiler ignores or does not see.
>

Anything that the compiler ignores is by definition unchecked, so any
desired conventions will be violated somewhere.  It would be possible to
adopt an internal system for const-ness (e.g. const_Vec) which would end up
typedef'd to plain Vec for non-library code so that users would not need
adopt this weird system.  It's still weird.


> For example
>
>  Input Parameters:
> +  const mat - the factored matrix
> -  const b - the right-hand-side vector
> .  x - the result vector
>

These annotations could be produced automatically if some typedefs were
adopted.  Or you could just write these things into the man page and leave
them unchecked, but that breeds inconsistencies.  (One way to fight
complexity is to have the compiler (and function guards) check that the
invariants I expect are actually enforced.  It is possible for this to get
out of control and become its own complexity.)

Which brings up a different point, what does Input Parameters and Output
> Parameters: mean, at times we are inconsistent for MatMult() we have
>
>   Input Parameters:
> +  mat - the factored matrix
> -  b - the right-hand-side vector
>
>   Output Parameter:
> .  x - the result vector
>
> this kind of means that mat and b are const and x is not, but usually the
> Output Paramater is reserved for when an object is created and passed out
> (which I like better).
>

Some documentation systems have an "in/out" attribute which indicates that
you have to pass in something valid, and it will be returned modified.

Jed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101202/aae5484b/attachment.html>