Private module procedures

Private module procedures

Post by pa » Fri, 30 Jan 2004 03:10:12


How do I make a procedure private to a module?

module testing
! want to expose function "good" but not function "secret".
! integer, PRIVATE:: secret ! doesn't work
contains
integer function good(i)
integer i
good= i
return
end function good

!integer, PRIVATE:: function secret(i) ! doesn't work
integer function secret(i)
integer i
! PRIVATE secret ! doesn't work either
bad= -i
return
end
end module testing

I could have sworn the first construct was legal. The Portland pgf90
(not sure what release) accepts it but Compaq Visual Fortran 6.6
doesn't. Both compilers reject the other two attempts. Is CVF
correct?

I could always move secret() to a module "testing_priv" which is used
only within "testing", but is there a better way?

--
pa at panix dot com
 
 
 

Private module procedures

Post by James Van » Fri, 30 Jan 2004 03:57:52


It's legal, but secret will not be interpreted as the name of a
module procedure. You need to say:

private secret

to make the module procedure secret private.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

 
 
 

Private module procedures

Post by Paul van D » Fri, 30 Jan 2004 04:05:29


I do it opposite to what you want to do. I make everything PRIVATE by default and then
explicitly set the module members I want PUBLIC:


! Make everyting PRIVATE by default
PRIVATE

! Make only the members I want PUBLIC, public.
PUBLIC :: good


Dunno which way is "better"...but the method above fits in with my perception anchor. :o)

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
 
 
 

Private module procedures

Post by pa » Fri, 30 Jan 2004 04:38:37


Good idea.

Thanks also to James Van Buskirk for the solution to my problem, which
was to use a private *statement* instead of a private *attribute*
in a (conflicting) declaration statement.

--
pa at panix dot com
 
 
 

Private module procedures

Post by Richard Ma » Fri, 30 Jan 2004 04:49:23


XXXX@XXXXX.COM (Pierre Asselin) writes:


private :: secret

or make the default private with just plain

private

(in which case, you'll need to declare those things public that
need to be).


That's because of the integer part. You can't redeclare
things about the procedure here. The interface of secret is
already known. You aren't allowed to redeclare it (much less
an incomplete part of it; the return type is part of the interface).


That's because the only place you can ever have PRIVATE is in
the part of a module before the contains.


It is, but it doesn't mean what you think. That would be
declaring something *ELSE* to be a private integer. Either
a variable or an external procedure (can't tell without more
context). You never declare the type (or anything else about
the interface) of a module procedure anywhere except in the
procedure itself.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
 
 
 

Private module procedures

Post by Steve Lion » Fri, 30 Jan 2004 05:53:19

On Wed, 28 Jan 2004 18:57:52 GMT, "James Van Buskirk" < XXXX@XXXXX.COM >



I don't think it's legal - the integer attribute, as you say, makes this
declaration of SECRET different from the module procedure. That means there
are two different SECRETs in the same scope, which is illegal.

As you say, simply using:

private secret

at the module level is the correct solution.


Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://www.yqcomputer.com/
Intel Fortran Support
http://www.yqcomputer.com/
 
 
 

Private module procedures

Post by Steve Lion » Sat, 31 Jan 2004 01:11:17

On Wed, 28 Jan 2004 19:38:37 +0000 (UTC), XXXX@XXXXX.COM (Pierre



It wasn't the statement vs. attribute, but your also giving a type to the
routine at the module level. That was what got you in trouble. Module
procedures define their own interfaces.


Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://www.yqcomputer.com/
Intel Fortran Support
http://www.yqcomputer.com/