Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CallBack functions in Fortran DLLs

0 views
Skip to first unread message

Laurie

unread,
May 14, 1999, 3:00:00 AM5/14/99
to

Is it possible to pass a subroutine address as an argument to another
subroutine (so that the latter may 'callback' the former) in Fortran?? I
wish to implement this in a DLL I am creating.

Thanks heaps for the help on my previous post. I have Upgraded to
Fortran PowerStation 4.

Cheers,
Laurie Green.

bg...@my-dejanews.com

unread,
May 14, 1999, 3:00:00 AM5/14/99
to
Laurie <l.g...@jktech.com.au> writes:

> Is it possible to pass a subroutine address as an argument to another
> subroutine (so that the latter may 'callback' the former) in Fortran?? I
> wish to implement this in a DLL I am creating.

Yes, that is possible. What you can't do yet (not portably, anyway) is
tuck away the address of the subroutine in a variable.

The old-fashioned, non-profile-safe way:
SUBROUTINE SUB (ACTION)
EXTERNAL ACTION
* ...
CALL ACTION (arguments)
* ...
END

SUBROUTINE DEED (args)
* ...
END

* ...
EXTERNAL DEED
CALL SUB (DEED)

The newfangled way, with explicit interfaces:

INTERFACE
SUBROUTINE SUB (ACTION)
IMPLICIT NONE
INTERFACE
SUBROUTINE ACTION (OBJECT)
USE M
IMPLICIT NONE
TYPE(T), INTENT(IN OUT) :: OBJECT
END SUBROUTINE ACTION
END INTERFACE
END SUBROUTINE SUB

SUBROUTINE SHOOT (TARGET)
USE M
IMPLICIT NONE
TYPE(T), INTENT(IN OUT) :: TARGET
END SUBROUTINE SHOOT
END INTERFACE

CALL SUB (SHOOT)

(Type T is declared in module M. The only interface block that is
always needed is the one describing the dummy argument to SUB; the
others can alternatively be provided by making SUB and SHOOT module
procedures. SUB could also be an internal procedure, but SHOOT
cannot: internal procedures may not be named as actual arguments.)

> Thanks heaps for the help on my previous post. I have Upgraded to
> Fortran PowerStation 4.

*Up*graded? To *that* compiler? Sounds like an oxymoron. Anyway, good luck.

ess...@ix.netcom.com

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
bg...@my-dejanews.com wrote:
>
> The old-fashioned, non-profile-safe way:

> EXTERNAL DEED
> CALL SUB (DEED)
>
> The newfangled way, with explicit interfaces:
>
> INTERFACE
> SUBROUTINE SUB (ACTION)
> IMPLICIT NONE
> INTERFACE
> SUBROUTINE ACTION (OBJECT)
> USE M
> IMPLICIT NONE
> TYPE(T), INTENT(IN OUT) :: OBJECT
> END SUBROUTINE ACTION
> END INTERFACE
> END SUBROUTINE SUB


It's painful to watch Fortran signal to noise ratio converging to
epsilon. This half ass blend of copycat work looketh like Fortran no
more -- might as well go all the way and switch to ADA. In the meantime,
those involved in this cloning perversion should reexamine the principal
ideas that guided Fortran evolution prior to this Standard_a_week
hysteria.

btw, that "non profile safe" way, whatever that means, has been *very
safe* for me as far back as I can remember...

--
Dr.B.Voh
-----------------------------------------------
Modeling * Simulation * Analysis
http://www.netcom.com/~essoft
-----------------------------------------------

0 new messages