On Thu, 10 Nov 2011, Jed Brown wrote: > On Wed, Nov 9, 2011 at 12:52, Barry Smith <bsmith at mcs.anl.gov> wrote: > > > So what both Satish's and Ethan's email are saying is so long as you tell > > the Fortran function the interface that shows the type being returned you > > can "trick" the Fortran into thinking that data type is just coming from > > another Fortran routine. > > > > I think this should resolve your issues and everything should be > > straightforward (no need for transfer function). Please let us know if this > > is problematic. > > > > Thanks everyone. This works, and in hindsight, I should have looked at > snes/examples/tutorials/ex5f90.F because it does this with > SNESGetApplicationContext. > > The unfortunate thing is that it appears that the user needs to write a > custom interface for each such function in order to get the compiler to > pass the pointer in a useful way. Is there a way for us to put some > interface definitions into the library? An (ugly) alternative would be to > provide some CPP macros that the user can use to get interface definitions > without needing to hand-type it (they would pass in their user-defined > type). > > How can we manage multiple contexts with different types in the same file? > It looks like perhaps I can put the interface definitions in different > modules, which I can import at subroutine granularity. If I want to get the > context out of two MatShells inside the same function, I would have to > write helper functions so that they can import different interface > definitions via different modules?
Perhaps we can use a generic interface definition - and then use 'transfer' function that Blaise refered to - in the user code. [I havne't yet tried this with the prior example code...] Satish
