Previous: Star Notation, Up: Types
The following notation specifies the kind-type selector of a type:
generic-type(KIND=n)
Use the above form where a type name is valid.
generic-type must be a generic type—one of
INTEGER
, REAL
, COMPLEX
, LOGICAL
,
or CHARACTER
.
n must be an integer initialization expression that
is a positive, nonzero value.
Programmers are discouraged from writing these values directly into their code. Future versions of the GNU Fortran language will offer facilities that will make the writing of code portable to g77 and Fortran 90 implementations simpler.
However, writing code that ports to existing FORTRAN 77 implementations depends on avoiding the `KIND=' construct.
The `KIND=' construct is thus useful in the context of GNU Fortran for two reasons:
The values of n in the GNU Fortran language are assigned using a scheme that:
The assignment system accomplishes this by assigning to each “fundamental meaning” of a specific type a unique prime number. Combinations of fundamental meanings—for example, a type that is two times the size of some other type—are assigned values of n that are the products of the values for those fundamental meanings.
A prime value of n is never given more than one fundamental meaning, to avoid situations where some code or system cannot reasonably provide those meanings in the form of a single type.
The values of n assigned so far are:
KIND=0
The planned future use is for this value to designate,
explicitly, context-sensitive kind-type selection.
For example, the expression `1D0 * 0.1_0' would
be equivalent to `1D0 * 0.1D0'.
KIND=1
REAL
, INTEGER
, LOGICAL
, COMPLEX
,
and CHARACTER
, as appropriate.
These are the “default” types described in the Fortran 90 standard, though that standard does not assign any particular `KIND=' value to these types.
(Typically, these are REAL*4
, INTEGER*4
,
LOGICAL*4
, and COMPLEX*8
.)
KIND=2
REAL(KIND=2)
is DOUBLE PRECISION
(typically REAL*8
),
COMPLEX(KIND=2)
is DOUBLE COMPLEX
(typically COMPLEX*16
),
These are the “double precision” types described in the Fortran 90 standard, though that standard does not assign any particular `KIND=' value to these types.
n of 4 thus corresponds to types that occupy four times as much storage as the default types, n of 8 to types that occupy eight times as much storage, and so on.
The INTEGER(KIND=2)
and LOGICAL(KIND=2)
types
are not necessarily supported by every GNU Fortran implementation.
KIND=3
CHARACTER
type,
which is the same effective type as CHARACTER(KIND=1)
(making that type effectively the same as CHARACTER(KIND=3)
).
(Typically, these are INTEGER*1
and LOGICAL*1
.)
n of 6 thus corresponds to types that occupy twice as much storage as the n=3 types, n of 12 to types that occupy four times as much storage, and so on.
These are not necessarily supported by every GNU Fortran
implementation.
KIND=5
(Typically, these are INTEGER*2
and LOGICAL*2
.)
n of 25 thus corresponds to types that occupy one-quarter as much storage as the default types.
These are not necessarily supported by every GNU Fortran
implementation.
KIND=7
INTEGER(KIND=7)
and
denotes the INTEGER
type that has the smallest
storage size that holds a pointer on the system.
A pointer representable by this type is capable of uniquely
addressing a CHARACTER*1
variable, array, array element,
or substring.
(Typically this is equivalent to INTEGER*4
or,
on 64-bit systems, INTEGER*8
.
In a compatible C implementation, it typically would
be the same size and semantics of the C type void *
.)
Note that these are proposed correspondences and might change in future versions of g77—avoid writing code depending on them while g77, and therefore the GNU Fortran language it defines, is in beta testing.
Values not specified in the above list are reserved to future versions of the GNU Fortran language.
Implementation-dependent meanings will be assigned new, unique prime numbers so as to not interfere with other implementation-dependent meanings, and offer the possibility of increasing the portability of code depending on such types by offering support for them in other GNU Fortran implementations.
Other meanings that might be given unique values are:
For example, some compilers offer options that cause
INTEGER
types to occupy the amount of storage
that would be needed for INTEGER(KIND=2)
types, but the
range remains that of INTEGER(KIND=1)
.
INTEGER(KIND=1)
.
These could permit, conceptually, use of portable code and
implementations on data files written by existing systems.
Future prime numbers should be given meanings in as incremental a fashion as possible, to allow for flexibility and expressiveness in combining types.
For example, instead of defining a prime number for little-endian IEEE doubles, one prime number might be assigned the meaning “little-endian”, another the meaning “IEEE double”, and the value of n for a little-endian IEEE double would thus naturally be the product of those two respective assigned values. (It could even be reasonable to have IEEE values result from the products of prime values denoting exponent and fraction sizes and meanings, hidden bit usage, availability and representations of special values such as subnormals, infinities, and Not-A-Numbers (NaNs), and so on.)
This assignment mechanism, while not inherently required for future versions of the GNU Fortran language, is worth using because it could ease management of the “space” of supported types much easier in the long run.
The above approach suggests a mechanism for specifying inheritance of intrinsic (built-in) types for an entire, widely portable product line. It is certainly reasonable that, unlike programmers of other languages offering inheritance mechanisms that employ verbose names for classes and subclasses, along with graphical browsers to elucidate the relationships, Fortran programmers would employ a mechanism that works by multiplying prime numbers together and finding the prime factors of such products.
Most of the advantages for the above scheme have been explained above. One disadvantage is that it could lead to the defining, by the GNU Fortran language, of some fairly large prime numbers. This could lead to the GNU Fortran language being declared “munitions” by the United States Department of Defense.