There is limited support for arrays of .NET objects declared using OBJECT or STRING. These differ from stanard Fortran arrays in that they are objects allocated on the managed (garbage collected) heap. These arrays must be declared with a zero lower bound on all dimensions. For example:
STRING :: s(0:9, 0:9)
OBJECT('System.Decimal') :: c(0:n)
This is exactly equivalent to:
OBJECT('System.String[,]') :: s
OBJECT('System.Decimal[]') :: c
s = NEW@('System.String[,]', 10, 10)
c = NEW@('System.Decimal[]', n+1)
An OBJECT array can be passed as an argument to a subroutine and (like a standard Fortran array) it can can take an assumed size or an assumed shape provided that the lower bounds are declared to be zero. An array of OBJECTs can also be used as an automatic array in a subroutine.
Note that
INTEGER(KIND=3) :: a(0:9)
and
OBJECT('System.Int32') :: a(0:9)
are equivalent arrays of 32-bit integers but they do not take the same form and are not handled in the same way. For a better performance, standard Fortran INTEGER arrays should be used whenever possible.
Limitations of OBJECT arrays
OBJECT arrays currently cannot appear in a MODULE, or in
a COMMON block or have the SAVE attribute (either explicitly or implicitly
via a DATA statement or variable initialisation).
Currently you cannot directly use the POINTER or ALLOCATABLE attribute in a declaration. For this you must use the first part of the equivalent syntax shown above. For example:
OBJECT('System.String[,]') :: s
declares a pointer to a two dimensional array of STRINGs.
Note that OBJECT arrays are allocated on the managed heap so there is no need to DEALLOCATE any variable that has been allocated using NEW@ (either implicitly or explicitly).
As yet OBJECT arrays cannot appear in array expressions (e.g. array-sections and whole-array expressions) or as whole-array arguments to any INTRINSIC (e.g. MATMUL and MAXVAL).