> Something really messed up the example: the "_"
> for example, and it looks like the function is being
> called recursively ???
[Alvaro] No. See below.
>
> Anyway the real problem is that the bounds may use
> a function only in a situation that establishes the
> size of a "dynamic" array--a dummy argument or in an
> ALLOCATE statement, or something like that. It has
> nothing to do with the fact that T is a component in
> a type definition. And the Absoft message is pretty
> strange.
[Alvaro] The idea is that the function NoOptVars() is pure and is used
to size the array in the derived type. NoOptVars_ with the "_" is a
_private saved variable_ which function NoOptVars() accesses and returns
as a value. My initial concern was that the function NoOPtVars() could
not be pure if accessed a saved entity, but the definition of pure
functions I have in "Fortran 90/95 Explained" seemed to say it was OK.
Thus, I wanted to be able to set NoOptVars_ to a value in some other
place of the code, and have the function NoOptVars() size the array. I
could have done this:
module A
! NoOptVars is set to a value somewhere else.
integer,save,public :: NoOptVars
end module A
module B
use A
type :: test_t
private
integer :: t(NoOptVars)
end type test_t
end module B
...but I wanted to have the flexibility of one day perhaps adding some
logic to the integer value used to size array t.
Does that make sense? My question is basically about what can be a
derived type specification expression and what can't be.
Alvaro
|