Fortran - static function ? how ?

Author

static function ? how ?

2005-05-26, 8:57 am

Hi,

In C language, we can use:

/* foo.c */
static void foo(void)
{
....
}

to define a static function "foo" which is
local function of file "foo.c".

Can I do the same thing in Fortran ? How ?
I'm using g77. Thanks.

Best Regards
KC
kccheng@linuxdaq-labs.org

Arjen Markus

2005-05-26, 8:57 am

KC wrote:
>
> Hi,
>
> In C language, we can use:
>
> /* foo.c */
> static void foo(void)
> {
> ...
> }
>
> to define a static function "foo" which is
> local function of file "foo.c".
>
> Can I do the same thing in Fortran ? How ?
> I'm using g77. Thanks.
>
> Best Regards
> KC
> kccheng@linuxdaq-labs.org

You can do this using g95 (that is the GNU
compiler for Fortran 90/95):

Via the contains statement you can introduce new subroutines and
functions
that can only be accessed by each other and the containing routine:

subroutine suba( ... )
....
call subb( ... )
.....
contains
subroutine subb( ... )
write(*,*) 'In subb!'
end subroutine subb

subroutine subc( ... )
...
end subroutine subc

end subroutine suba

(The same for main programs). Modules are even more useful, because
more general.

Regards,

Arjen

Ian Bush

2005-05-26, 8:57 am

Hi,

KC wrote:

> Hi,
>
> In C language, we can use:
>
> /* foo.c */
> static void foo(void)
> {
> ...
> }
>
>
> to define a static function "foo" which is
> local function of file "foo.c".
>
> Can I do the same thing in Fortran ? How ?
> I'm using g77. Thanks.
>
>

You can't in F77, so why not upgrade to F90 ? Your URL
suggests that you can get a copy of the Intel compiler for free.

You can't do exactly the same in F90, as there is no such thing as file
scope, but you can do something very similar with modules:

Module baz

Implicit None

Public :: bar ! The outside world can see bar

Private ! By default nothing can be seen in the module
! unless declared public

Contains

Subroutine foo( ... ) ! Private, so can only be seen by routines in
! the module
....
End Subroutine foo

Subroutine bar( ... ) ! Public, so can be seen outside the module
....
End Subroutine bar

End Module baz

Modules provide mechanisms that are much more powerful than the simple
file scope provided by C, so I would strongly suggest you look into them,

Hope this helps,

Ian

2005-05-26, 9:00 pm

Ian Bush wrote:
>
> You can't do exactly the same in F90, as there is no such thing as file
> scope, but you can do something very similar with modules:
>
> Module baz
> Public :: bar ! The outside world can see bar
> Private ! By default nothing can be seen in the module
> ! unless declared public
> Contains
> Subroutine foo( ... ) ! Private, so can only be seen by routines in
> ! the module

Sighhh! When outa gas look for alternatives, like dlls - any object
that's not (explicitly) exported is "private* to dll - with *zero*
programming overhead, quite unlike the sprawling module headaches
proposed above.

Rich Townsend

2005-05-26, 9:00 pm

bv wrote:
> Ian Bush wrote:
>
>
>
> Sighhh! When outa gas look for alternatives, like dlls - any object
> that's not (explicitly) exported is "private* to dll - with *zero*
> programming overhead, quite unlike the sprawling module headaches
> proposed above.
>

An utterly useless solution for those on non-Windows systems. Well done
as usual, Mr Voh.

Jan Vorbrüggen

2005-05-31, 9:10 am

>>Sighhh! When outa gas look for alternatives, like dlls - any object

Zero programming overhead for generating a DLL while hiding some of the
names? Do say.
[color=darkred]
> An utterly useless solution for those on non-Windows systems. Well done
> as usual, Mr Voh.

That of course is not true. They might be called differently, but any OS
I've worked on (and those are more than I have fingers) had 'em in some
guise.

Jan

Rich Townsend

2005-05-31, 4:01 pm

Jan Vorbrüggen wrote:
>
>
> Zero programming overhead for generating a DLL while hiding some of the
> names? Do say.
>
>
>
>
> That of course is not true. They might be called differently, but any OS
> I've worked on (and those are more than I have fingers) had 'em in some
> guise.
>
>

Sure, most OSs have dynamically-loadable libraries. However, B. Voh
seems to think that Microsoft's particular implementation, usually
referred to as a "DLL" (contrast with the Unix nomenclature of "shared
libary"), are a magic bullet for all ills. Of course, how dynamic
libaries *in general* can address namespace issues and data hiding -- in
a portable manner -- is beyond me....

cheers,

Rich

Sponsored Links