<div dir="ltr">Sounds good.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 11, 2013 at 1:18 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Jan 11, 2013, at 1:02 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
> On Fri, Jan 11, 2013 at 12:58 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
><br>
><br>
</div><div class="im">> So this works by convention that we name the argument to match the man page (e.g., SNESFunction) in all interfaces?<br>
<br>
</div>   Yes<br>
<div class="im"><br>
> The compiler won't help to enforce that consistency,<br>
<br>
</div>   Not yet, but maybe a couple tweaks to LLVM will get us there :-)<br>
<div class="im"><br>
> but it'll deal with the documentation duplication.<br>
<br>
</div>   Yes (and missing in some functions like SNESGetFunction() and not existing like in other places).<br>
<span class="HOEnZb"><font color="#888888"><br>
  Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> Is this a good middle-ground? Something wrong with it?<br>
><br>
>   Barry<br>
><br>
> > Cons of typedef:<br>
> > * typedef is less transparent when reading code<br>
> > * information is more scattered (harder for people that don't have the source code indexed and don't know where to find definitions)<br>
> > * because every usage does not need to be updated, it's hard to determine consequences of a change when reading diff<br>
> ><br>
> > I'll stop using function pointer typedefs if you don't like them.<br>
> ><br>
> > On Fri, Jan 11, 2013 at 10:26 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> ><br>
> >    The thing I don't like about typedef's for function pointers is that they do not display the calling sequencing in the code<br>
> ><br>
> >   For example  from<br>
> ><br>
> > > typedef struct _n_TSDM *TSDM;<br>
> > > struct _n_TSDM {<br>
> > >   TSRHSFunction rhsfunction;<br>
> ><br>
> >   or<br>
> ><br>
> >    PetscErrorCode TSSetRHSFunction(TS ts, TSRHSFunction rhsfunction)<br>
> ><br>
> >   I have no freaking idea what the calling sequence of rhsfunction is. but with<br>
> ><br>
> > > typedef struct _n_TSDM *TSDM;<br>
> > > struct _n_TSDM {<br>
> > >   PetscErrorCode (*TSRHSFunction)(TS,PetscReal,Vec,Vec,void*);<br>
> ><br>
> >  or<br>
> ><br>
> >     PetscErrorCode TSSetRHSFunction(TS ts, PetscErrorCode (*TSRHSFunction)(TS,PetscReal,Vec,Vec,void*);<br>
> ><br>
> > boom I know exactly the calling sequence.<br>
> ><br>
> >    Maybe there is some way we can do manual pages for these beasties and consistency of names in different locations so we get the best of both worlds?<br>
> ><br>
> >    Barry<br>
> ><br>
> ><br>
> ><br>
> > On Nov 25, 2012, at 3:58 AM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > > On Sun, Nov 25, 2012 at 4:42 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> > ><br>
> > > typedef struct _n_KSPDM *KSPDM;<br>
> > > struct _n_KSPDM {<br>
> > >   PetscErrorCode (*computeoperators)(KSP,Mat,Mat,MatStructure*,void*);<br>
> > >   PetscErrorCode (*computerhs)(KSP,Vec,void*);<br>
> > >   PetscErrorCode (*computeinitialguess)(KSP,Vec,void*);<br>
> > ><br>
> > > typedef struct _n_SNESDM *SNESDM;<br>
> > > struct _n_SNESDM {<br>
> > >   PetscErrorCode (*computefunction)(SNES,Vec,Vec,void*);<br>
> > >   PetscErrorCode (*computegs)(SNES,Vec,Vec,void*);<br>
> > >   PetscErrorCode (*computejacobian)(SNES,Vec,Mat*,Mat*,MatStructure*,void*);<br>
> > ><br>
> > >   /* objective */<br>
> > >   PetscErrorCode (*computeobjective)(SNES,Vec,PetscReal*,void*);<br>
> > ><br>
> > ><br>
> > > typedef struct _n_TSDM *TSDM;<br>
> > > struct _n_TSDM {<br>
> > >   TSRHSFunction rhsfunction;<br>
> > >   TSRHSJacobian rhsjacobian;<br>
> > ><br>
> > >   TSIFunction ifunction;<br>
> > >   TSIJacobian ijacobian;<br>
> > ><br>
> > > The PETSc style guide says  to avoid typedef of function pointers unless there is a damn good reason to use them (or it should);<br>
> > ><br>
> > > Can we revisit this choice in the interest of writing one man page that documents the assumptions that one can make about a callback routine? I hate duplicating the same information in TS{Set,Get}IFunction() and DMTS{Set,Get}IFunction(). Also, if a typedef is used everywhere, we can more reliably find all places that depend on it. (using grep or M-x gtags-find-symbol).<br>

> > ><br>
> > > but why use them for TS but not for SNES or KSP functions?<br>
> > ><br>
> > > Because they were already defined for use with TSSetIFunction()/TSGetIFunction().<br>
> ><br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>