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

Interface for functions

1 view
Skip to first unread message

Alexander Mai

unread,
Aug 24, 1999, 3:00:00 AM8/24/99
to

I wonder what's the best way to collect interfaces to
functions (subroutines) in a module.
Here's an example which doesn't work ...

module interfmod

interface
real function foo()
end function foo

real function bar()
end function bar
end interface
end module interfmod


real function foo()

use interfmod

foo = 1.+bar()
end function


For obvious reasons I do not want to have a single module
for each function but with the given code I get an error:

foo: This name has already been used as an external function name

and similar messages. Perhaps I just missed some basic principle
of Fortran 90? My idea was to use a module including this interface block
like a header in C containing prototypes ...


--
Alexander Mai
st00...@hrzpub.tu-darmstadt.de

Michael Metcalf

unread,
Aug 24, 1999, 3:00:00 AM8/24/99
to

I wonder what's the best way to collect interfaces to
functions (subroutines) in a module.
========================================================
Well, unless you're dealing with legacy code, you don't need to.
You just put all your procedures in a module, following a
CONTAINS statement, and they can all call one another happily as
the interfaces are then explicit without having interface blocks
at all. All you need in addition is a main program that uses the
module and calls one or more of its procedures.

Hope that helps,

Mike Metcalf


--

bg...@my-deja.com

unread,
Aug 24, 1999, 3:00:00 AM8/24/99
to
st00...@sub1.hrz.tu-darmstadt.de (Alexander Mai) writes:

> I wonder what's the best way to collect interfaces to
> functions (subroutines) in a module.

> Here's an example which doesn't work ...

[...]
> real function foo()
> use interfmod ! Where interfmod declares an interface for foo()
[...]

This is a well-known limitation of Fortran: it won't allow you to
specify an interface twice. Either put the source code for foo()
directly in module interfmod (and remove that unnecessary USE
statement in foo's body), or find some other way of making the
interface of bar() explicit within foo(). Things get harder if
you want foo() to have access to some global variables in interfmod:
then only the first approach is workable. (Although you could always
put the global variables in another module which you then USE from
within interfmod.)

If you are thinking along these lines, you are also likely to run
into that other well-known problem about duplicate declarations of
a derived type yielding mutually incompatible types unless the SEQUENCE
attribute is used.

If you aren't prepared to incorporate foo() and bar() themselves into
modules yet, you are probably better off forgoing the interface
checking within these routines (it's well-tested legacy code after
all, isn't it? if so, the less you change it, the better) and
using an automated tool to generate interfmod. The rules for interface
blocks are such that one can generate them automatically by taking
the source code of the corresponding procedures and removing all
executable statements except the final END.

Michel OLAGNON

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
In article <7pucod$9cc$1...@sun27.hrz.tu-darmstadt.de>, st00...@sub1.hrz.tu-darmstadt.de (Alexander Mai) writes:
>
>I wonder what's the best way to collect interfaces to
>functions (subroutines) in a module.
>Here's an example which doesn't work ...
>
>module interfmod
>
>interface
>real function foo()
>end function foo
>
>real function bar()
>end function bar
>end interface
>end module interfmod
>
>
>real function foo()
>
>use interfmod


Replace this with:

use interfmod, except_for => foo

(Of course, you may rename ``foo'' to anything else, but
except_for is very readable)

>
>foo = 1.+bar()
>end function
>
>
>For obvious reasons I do not want to have a single module
>for each function but with the given code I get an error:
>
> foo: This name has already been used as an external function name
>
>and similar messages. Perhaps I just missed some basic principle
>of Fortran 90? My idea was to use a module including this interface block
>like a header in C containing prototypes ...
>
>
>--
>Alexander Mai
>st00...@hrzpub.tu-darmstadt.de

Michel

--
| Michel OLAGNON email : Michel....@ifremer.fr|
| IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer|
| Centre de Brest - B.P. 70 phone : +33-2-9822 4144|
| F-29280 PLOUZANE - FRANCE fax : +33-2-9822 4650|
| http://www.ifremer.fr/ditigo/molagnon/molagnon.html |


Alexander Mai

unread,
Sep 1, 1999, 3:00:00 AM9/1/99
to
In article <7purcf$ahe$1...@ssauraaa-i-1.production.compuserve.com>,

you write:
|>
|> I wonder what's the best way to collect interfaces to
|> functions (subroutines) in a module.
|> ========================================================
|> Well, unless you're dealing with legacy code, you don't need to.
|> You just put all your procedures in a module, following a
|> CONTAINS statement, and they can all call one another happily as
|> the interfaces are then explicit without having interface blocks
|> at all. All you need in addition is a main program that uses the
|> module and calls one or more of its procedures.
|>
|> Hope that helps,
|>
|> Mike Metcalf

Thanks (also to all other who replied)!

I somehow missed this approach completly and now made modules
out of all my files containing functions/subroutines.

To handle the dependencies of the files I would have some
tools if we were talking about C where you can check which
file #includes (and therefore depends on) each other.

Now I have to manually add some dependencies to my Makefile and
also take care that there are no circular references?! (the latter
can be addressed by splitting up the modules, of course)

The compiler I use creates .mod files for each module, so
a missing dependency seems to work if there are still old
.mod files available. But that's not the desired way since
this likely will cause problems!?
If the project is rather small (<= 10 source files) it may be
ok, but I don't want to write a Makefile for a bigger one ...


--
Alexander Mai
st00...@hrzpub.tu-darmstadt.de

0 new messages