Re: Strange behavior using a module which uses another module
- From: deltaquattro <deltaquattro@xxxxxxxxx>
- Date: Thu, 31 Jul 2008 10:18:37 -0700 (PDT)
On 31 Lug, 18:51, ka...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx (Steven G. Kargl)
wrote:
In article <ba7b849c-3c46-4bc8-98e4-9f48fed9c...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,[..]
deltaquattro <deltaquat...@xxxxxxxxx> 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?
See above.
Maybe my example wasn't very clear. Obviously, in the example I
posted, in order for main to work, it must have access to dgamma by
host association, and yours is a way to allow it. However, question 1)
wasn't related exactly to this case, but to a similar, however
slightly different one. Suppose I have a program unit A, accessing
module B, and module B accessing module C:
program A
use B
end program A
module B
use C
..
end module B
module C
..
end module C
I want A to have access only to entities defined in B and not to C,
and I don't want to do it like this:
module B
use C
private :: sub1_C, sub2_C,...
..
end module B
otherwise each time I modify C I have to modify B. I'd also rather not
do this (suggested by Tobias), unless there's no other way:
module B
use C
private
public :: sub1_B, sub2_B,...
..
end module B
otherwise I'll have to increase the PUBLIC list each time I modify B.
Clearly this is less of a problem because the modification stays local
to B, however it's a possible source of error, so if there's an
"automatic" way of declaring only all entities in C as PRIVATE, I
believe it would be better.
Best regards,
deltaquattro
.
- Follow-Ups:
- Re: Strange behavior using a module which uses another module
- From: Paul van Delst
- Re: Strange behavior using a module which uses another module
- References:
- Strange behavior using a module which uses another module
- From: deltaquattro
- Re: Strange behavior using a module which uses another module
- From: Steven G. Kargl
- Strange behavior using a module which uses another module
- Prev by Date: Re: Strange behavior using a module which uses another module
- Next by Date: Re: Strange behavior using a module which uses another module
- Previous by thread: Re: Strange behavior using a module which uses another module
- Next by thread: Re: Strange behavior using a module which uses another module
- Index(es):
Relevant Pages
|