Van Snyder wrote:
> You can declare your DIM parameter to be a KIND parameter instead of a NONKIND
> one.
Thanks. The name KIND then is somewhat misleading, though I guess the
dimensionality of a physical problem can be considered a "kind" (not in the
Fortran type sense though). The type :: point example (or something almost
identical) is given as an example in the standard, and this probably mislead me.
There is also an example there for huge_matrix (or something like that), which
seems a lot more appropriate.
> Malcolm expects that nonkind parameters, which can effectively only be
> ultimately used for character lengths and array dimensions, will result
> in ultimate components that are parameterized by them being allocatable.
The benefits of them are then more syntactical, and one should not rely on them
for efficiency. But it is nontheless a nifty feature. For example, the compiler
will know the sizes, extents, etc of all the arrays, and so a simple ALLOCATE for
the type would allocate all the arrays needed accordingly (since most problems are
in fact characterized by a few size numbers, such as the number of variables,
points, edges, etc.):
type :: linear_system(n) ! Solve Ax=b
integer, nonkind :: n
real, dimension(n) :: x(n), b(n), A(n,n)
end type
type(linear_system(*)), allocatable :: my_system ! Syntax?
allocate(my_system(100)) ! Allocates all arrays accordingly with just one
statement!
Also, the compiler can do compile-time checks on array extents (in array
expressions for example), and maybe even optimize better on occasions.
> One can imagine that at some date in the distant future a very clever optimizer
> might do better, at least for objects that are never arguments, but don't
> hold your breath.
Yeah, I would agree that expecting the compiler to do away with its usual array
descriptor (for example, in the type linear_system a total of three addresses and
1 integer is needed, as opposed to a whole-lot more for three descriptors if the
arrays were allocatable array components), is a bit much for now. But some day it
could happen. Sadly, it is exactly such funcationality that I long in Fortran (to
avoid wasted space on array descriptors)...
Now understands parametrized types (better),
Aleksandar
|