(j3.2006) Problem with default expressions for kind type parameters?
Rafik Zurob
rzurob
Fri Sep 21 21:52:04 EDT 2012
Hello
Bill Long wrote on 21/09/2012 04:45:58 PM:
> On 9/21/12 3:38 PM, Van Snyder wrote:
> > I don't see an argument for w%k == 6.
>
> It depends on whether the compiler can determine the initialization
> value for k = (5+1) at the time the definition of the type is compiled,
> which would be consistent with the previous concepts of "initialized",
> or whether the compiler has to dynamically recompute the initialization
> values for every declaration of a variable of the type.
I agree with Van. This should be done at variable declaration time. If
someone writes code like this, they clearly intended k to be 1 more than
j, unless they explicitly provide a value for k.
For example, assume that a compiler supports kinds 4, 8, and 16 for REAL.
One might write:
type dt(k)
integer, kind :: k = 4
real(k) s
real(k*2) d
end type
type(dt) d1 ! real(4), real(8)
type(dt(4)) d2 ! real(4), real(8)
type(dt(8)) d3 ! real(8), real(16)
I think you'd agree that d3%d should be 8. But as the number of
components increases and the expressions get more complicated, the user
might not want to repeat (and maintain) these expressions in many places.
So they could write:
! Note to self: don't specify a value for double_k explicitly
type dt(k, double_k)
integer, kind :: k = 4, double_k = 2 * k
real(k) s
real(double_k) d
end type
type(dt) d1 ! real(4), real(8)
type(dt(4)) d2 ! real(4), real(8)
type(dt(8)) d3 ! real(8), real(16)
In this case, my fictional user could also (but would not) do this:
type(dt(double_k=16)) d4 ! real(4), real(16).
> I can assure
> you that the second option will further deter vendors from implementing
> this feature.
I doubt this will be the hair that breaks the camel's back. From
experience, there are far worse aspects to implementing parameterized
derived types, especially when it comes to length type parameters.
This is what XLF outputs for your original example:
$ a.out
5 6
10 11
$
I think Malcolm's suggestion about "a previously declared kind type
parameter of the type being defined" is reasonable.
Regard
Rafik
More information about the J3
mailing list