Prev: string stuff
Next: distance between points on the earth
From: Geico Caveman on 12 Oct 2009 13:14
On 2009-10-12 08:53:48 -0700, Ron Shepard
<ron-shepard(a)NOSPAM.comcast.net> said:

> In article <2009101207322575249-spammersgohere(a)spaminvalid>,
> Geico Caveman <spammers-go-here(a)spam.invalid> wrote:
>
>> Tried this with Intel Fortran Professional (ifort). Now, I get an error
>> stating that a kind type parameter must be a compile-type constant.
>
> The problem is that the interface block cannot see the mptr
> parameter through host association. You need to write a separate
> module that defines the parameter and USE that module within the
> interface block. Or, just move the parameter definition into the
> interface block (e.g. if this is the only place it is used).
>
> BTW, selected_int_kind(9) is probably not the same precision as the
> constant kind value 8 (the latter of which is compiler dependent, of
> course). Is that a typo, or are you trying to extend the precision
> to 64-bit integers or something?
>
> $.02 -Ron Shepard


I tried using a module with such a definition inside the interface
block (but outside function declarations). It did not work (its a
syntax error). I had to put the use statement inside function
declaration. I have about 10-15 function declarations, so this is very
cumbersome.

Yes, I am trying to run this on a 64-bit machine. The original code
claims that kind value = 8 corresponds to 64-bit integers, but leave
out details about which compiler / platform they were using. Since
their code is about 9 years old, and came with DOS line terminators.

Which suggests that they used a windows machine to edit their code, and
a Linux / Sun / HP machine to compile and run it. That narrows it down
a little, but not much.

From: Geico Caveman on 12 Oct 2009 13:15
On 2009-10-12 07:42:53 -0700, m_b_metcalf <michaelmetcalf(a)compuserve.com> said:

>
> Your problem is that the interface forms its own scoping unit banging
> a hole in the scoping unit formed by the module. Thus, it doesn't have
> access to anything specified in the module. You need to separate the
> two parts of the module into separate modules, as in :
>
> module mex
> implicit none
> integer, parameter :: mptr=selected_int_kind(9)
> end module mex
>
> module two
> interface
> integer(kind=mptr) function mexGetPr(pm)
> use mex
> integer(kind=mptr) :: pm
> end function mexGetPr
>
> end interface
> end module two
>
> See also the recent thread "public declaration isn't visible inside an
> interface?".
>
> HTH
>
> Mike Metcalf

Thanks !

That works except that it is cumbersome to use.

From: dpb on 12 Oct 2009 13:20
Geico Caveman wrote:
....
> That [a module] works except that it is cumbersome to use.

See other note iff have F03 implemented IMPORT statement in your compiler...

--


From: Geico Caveman on 12 Oct 2009 13:34
On 2009-10-12 10:20:53 -0700, dpb <none(a)non.net> said:

> Geico Caveman wrote:
> ...
>> That [a module] works except that it is cumbersome to use.
>
> See other note iff have F03 implemented IMPORT statement in your compiler...


It does.

When I look at the book, the import statement needs to be:

1. inside an interface body
2. inside each function declaration.

From an ease of coding perspective, I see no difference between import and use.

If it allowed something like:

module mex

integer, parameter :: mptr=selected_int_kind(9)

interface

import :: mptr

integer (kind=mptr) function(...)
....
end function

! 20 more such functions
....

end interface

end module

I could see its utility, but it doesn't. Maybe I am missing something again ?

From: dpb on 12 Oct 2009 14:27
Geico Caveman wrote:
....
> If it allowed something like:
>
> module mex
> integer, parameter :: mptr=selected_int_kind(9)
>
> interface
> import :: mptr
> integer (kind=mptr) function(...)
> ...
> end function
> ! 20 more such functions
> ...
>
> end interface
>
> end module
>
> I could see its utility, but it doesn't. Maybe I am missing something
> again ?

It obviates the need for the other module.

Don't see anyway around the inclusion of the import statement in each
function interface block owing to the past decision that they don't
otherwise inherit anything.

If you read Richard M's response to my short answer in the other thread
you'll see the discussion amplified.

The problem is that choice was made and now there's the fact that have
to live w/ it for compatability's sake, for good or ill.

So, don't think you really missed anything other than, perhaps, context
of how got here.

--


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: string stuff
Next: distance between points on the earth