Aleksandar Donev writes:
> 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).
Could well be in the Fortran type sense. Heck, if you were making a
software extended precision package, you might have different internal
dimension sizes for different kinds and want to do things like generic
resolution on them.
One thing you may not have picked up is that you don't actually *HAVE*
to use a type parameter in the components of a type at all. Most of
the time you will, but there are concievable cases where you might add
a kind type parameter solely in order to force a derived type to have
two kinds that are incompatable, even though they have no internal
structural differences. This would allow you to do things like
generic resolution based on the difference.
Indeed, you can have a derived type that has no components, but is
used only to force generic resolution. A bit strange, but I've
seen stranger things. Indeed, I've seen things that looked very
simillar to this (look at the f90 version of the NAG library,
which has some arguments that serve no purpose other than
generic resolution).
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|