Re: Internal procedures as dummy arguments in gfortran?

[Arjen Markus <arjen dot markus895 at gmail dot com>]

2009/9/24 Miguel Hermanns <hermanns@tupi.dmt.upm.es>:
> Hi Arjen,
>
> thanks for the example, but as you say there are several limitations.
> Additionally, the subroutine, in your case integrate_fg, must have access to
> the eval_at function through host association, and that is a very strong
> limitation, since every time you want to expand the functionality, you need
> to copy the lines of the venerable subroutine to each of the new subroutines
> you create, since otherwise you never have access to the corresponding
> eval_at function through host association.
>
> Imagine the extreme case where you want to use instead a compiled
> subroutine, be it IMSL, MKL or what ever. That is the case I like to think
> and design on, because there the code is perfectly separated in its
> functionality and it is much easier to develop, structure, validate. I know
> I'm picky :-)
>

Hi Miguel,

yes, it is a method that has its limitations, but you could use the
INCLUDE statement to prevent actually copying the source code
(the compiled code will be present in multiple copies of course).

With procedure pointers things look a bit brighter, as you could
then store the pointers to the functions f and g in my example
and do it like this:

- Store the pointers to f and g, making sure eval_at has access to them
  (via a module for instance)
- Pass eval_at to the original integration routine (which can now be
  completely separate)

This does not solve the problem that module variables are not
thread-safe ...

Regards,

Arjen
module

real function eval_at(