Strange behavior using a module which uses another module
  Home FAQ Contact Sign in
comp.lang.fortran only
 
Advanced search
POPULAR GROUPS

more...

comp.lang.fortran Profile…
 Up
Strange behavior using a module which uses another module         


Author: deltaquattro
Date: Jul 31, 2008 09:27

Hi,

it's me again :-) I'm testing my function libraries against a standard
library and I don't understand what's happening. The libraries I
developed are called md_Jacobi and md_Global_funcs. The standard
library function is dgamma.f from SPECFUN.

module md_Global_funcs
contains
...
real function lgamma(x)
...
write(*,*) 'foo' ! Keep in mind this instruction...
...
end function lgamma
...
end module md_Global_funcs

module md_Jacobi
use md_Global_funcs
....
end module md_Jacobi
Show full article (2.29Kb)
20 Comments
Re: Strange behavior using a module which uses another module         


Author: Ron Shepard
Date: Jul 31, 2008 09:45

In article
y38g2000hsy.googlegroups.com>,
deltaquattro gmail.com> wrote:
> 1) I was surprised that main was able to access gamma, lgamma and
> factorial, defined in md_Global_funcs, since main only uses md_Jacobi
> and not md_Global_funcs. However, I looked at MRC and found that since
> md_Jacobi uses md_Global_funcs, then main has access to it also. Is it
> possible to let a program unit A use a module B, without having access
> to any module used by B unless explicitly used by A?

Yes, access to module and local variables in a module are controlled
with PUBLIC, PRIVATE, and ONLY. If necessary, you can also define
local aliases in order to avoid conflicts with two or more functions
that have the same name.
> 2) compiling with EFC, I get the following error:
[...]
> due to the "write" instruction in lgamma. Why is the compiler
> complaining about a recursive I/O? How can I use print/write
> statements to debug my libraries without incurring in this error?

Don't do recursive I/O. For example
Show full article (1.43Kb)
no comments
Re: Strange behavior using a module which uses another module         


Author: Tobias Burnus
Date: Jul 31, 2008 09:45

On Jul 31, 6:27 pm, deltaquattro gmail.com> wrote:
> module md_Global_funcs
> contains
>   real function lgamma(x)
> end module md_Global_funcs
>
> module md_Jacobi
> use md_Global_funcs
> end module md_Jacobi
>
> program main
> use md_Jacobi

Here, you should be able to access lgamma of module md_Global_funcs,
which you import via module md_Jacobi. If this is not desired, you
have to use either "USE ..., ONLY:" or use PRIVATE/PUBLIC statements
in md_Jacobi.
> external dgamma

(This declares dgamma as external procedure.)
Show full article (2.22Kb)
no comments
Re: Strange behavior using a module which uses another module         


Author: Steven G. Kargl
Date: Jul 31, 2008 09:51

In article y38g2000hsy.googlegroups.com>,
deltaquattro gmail.com> writes:
> it's me again :-) I'm testing my function libraries against a standard
> library and I don't understand what's happening. The libraries I
> developed are called md_Jacobi and md_Global_funcs. The standard
> library function is dgamma.f from SPECFUN.
>
> module md_Global_funcs

private ! Make all symbols private
public dgamma, ... ! Only make the desired symbols public.
Show full article (2.09Kb)
no comments
Re: Strange behavior using a module which uses another module         


Author: deltaquattro
Date: Jul 31, 2008 10:04

On 31 Lug, 18:45, Tobias Burnus wrote:
> On Jul 31, 6:27 pm, deltaquattro gmail.com> wrote:
[..]
>> Is it
>> possible to let a program unit A use a module B, without having access
>> to any module used by B unless explicitly used by A?
>
> module B
>   use C
>   private
>   public :: B_subroutine1, B_subroutine2, B_global_var1, B_type
>
Show full article (1.45Kb)
no comments
Re: Strange behavior using a module which uses another module         


Author: deltaquattro
Date: Jul 31, 2008 10:18

On 31 Lug, 18:51, ka...@troutmask.apl.washington.edu (Steven G. Kargl)
wrote:
> In article y38g2000hsy.googlegroups.com>,
>         deltaquattro gmail.com> writes:
>
>> it's me again :-) I'm testing my function libraries against a standard
>> library and I don't understand what's happening. The libraries I
>> developed are called md_Jacobi and md_Global_funcs. The standard
>> library function is dgamma.f from SPECFUN.
>
>> module md_Global_funcs
>
>   private            ! Make all symbols private
>   public dgamma, ... ! Only make the desired symbols public.
[..]
>> 1) I was surprised that main was able to access gamma, lgamma and
>> factorial, defined in md_Global_funcs, since main only uses md_Jacobi
>> and not md_Global_funcs. However, I looked at MRC and found that since
>> md_Jacobi uses md_Global_funcs, then main has access to it also. Is it
>> possible to let a program unit A use a module B, without having access ...
Show full article (2.26Kb)
no comments
Re: Strange behavior using a module which uses another module         


Author: Paul van Delst
Date: Jul 31, 2008 10:51

deltaquattro wrote:
> On 31 Lug, 18:51, ka...@troutmask.apl.washington.edu (Steven G. Kargl)
> wrote:
>> In article y38g2000hsy.googlegroups.com>,
>> deltaquattro gmail.com> writes:
>>
>>> it's me again :-) I'm testing my function libraries against a standard
>>> library and I don't understand what's happening. The libraries I
>>> developed are called md_Jacobi and md_Global_funcs. The standard
>>> library function is dgamma.f from SPECFUN.
>>> module md_Global_funcs
>> private ! Make all symbols private
>> public dgamma, ... ! Only make the desired symbols public.
> [..]
>>> 1) I was surprised that main was able to access gamma, lgamma and
>>> factorial, defined in md_Global_funcs, since main only uses md_Jacobi
>>> and not md_Global_funcs. However, I looked at MRC and found that since
>>> md_Jacobi uses md_Global_funcs, then main has access to it also. Is it
>>> possible to let a program unit A use a module B, without having access
>>> to any module used by B unless explicitly used by A? ...
Show full article (3.00Kb)
no comments
Re: Strange behavior using a module which uses another module         


Author: James Giles
Date: Jul 31, 2008 12:23

Paul van Delst wrote:
...
> How would some sort of "automatic" method that you want be less prone
> to error?

I agree with pretty much everything PvD says except (sort of)
this last. In one case that deltaquattro mentioned, I think he's
got a very good point: there should be a way, when you USE
one module inside another to explicitly declare that you don't
want to "trans-ship" the contents any further. His proposed
syntax isn't bad:

USE mod1, (private|public) [rename-list]
or
USE mod1, (private|public), only: only-list

Where, the latter case, the ONLY and PRIVATE/PUBLIC keywords
can appear in either order. Of course, I always have an ONLY, so
the first I would still consider bad style. You make a constraint
that the PRIVATE/PUBLIC keyword here can only be used if the USE
statement is in the specification-part of a MODULE. Only one of
PRIVATE or PUBLIC can appear, not both.
Show full article (1.46Kb)
no comments
Re: Strange behavior using a module which uses another module         


Author: James Van Buskirk
Date: Jul 31, 2008 18:56

"deltaquattro" gmail.com> wrote in message
news:ba7b849c-3c46-4bc8-98e4-9f48fed9c4ba@y38g2000hsy.googlegroups.com...
> dgamma(real(i))

I seem to have missed part of the discussion. Does function dgamma
accept a default real argument in your case or do you need
dgamma(dble(i))?

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
no comments
Re: Strange behavior using a module which uses another module         


Author: Reinhold Bader
Date: Jul 31, 2008 23:48

If module C is small, you could declare the entities from C private
in B. The disadvantage is that you need to update C whenever you
extend B.

deltaquattro schrieb:
> On 31 Lug, 18:45, Tobias Burnus wrote:
>> On Jul 31, 6:27 pm, deltaquattro gmail.com> wrote:
> [..]
>>> Is it
>>> possible to let a program unit...
Show full article (1.66Kb)
no comments

RELATED THREADS
SubjectArticles qty Group
Problematic UPDATE behavior when using parameterized queriesmicrosoft.public.sqlserver.ce ·
1 2 3