(j3.2006) Is this or is this not F95-standard conformant?

Van Snyder Van.Snyder
Wed Nov 10 21:03:33 EST 2010

On Wed, 2010-11-10 at 17:29 -0800, Malcolm Cohen wrote:
> Van Snyder wrote:
> > Is line 19 of the little attached program F95-standard conformant?
> Obviously not.
> > It looks like items (7)(d) and (7)(second b) at [97-007r2:94:17,21]
> > allow it, since the property inquired about is the kind type parameter
> > value.  In 10-007 the equivalent is 7.1.12p1(4)(b) at [151:29].
> "An initialization expression is a constant expression in which ... and where 
> each subscript ... is an initialization expression."

Yeah, I should have noticed that at [10-007:152:14-15].  I was in a
hurry to believe that my colleage had a good argmument.

Can I replace "i" with "1" in the case that h%x is associated, even if
"1" is out of bounds, since there is no reference involved?

    real(kind(h%x(i)%v)), intent(in), optional :: F
    real(kind(h%x(1)%v)), intent(in), optional :: F

I certainly can't use "lbound(h%x,1)".  Can I use "1" when h%x is not
associated (the real code where this example came from is going to
allocate it)?

All I want is the kind of the v component of h%x(something) in order to
declare a dummy argument that needs to be of the same kind.

In a different galaxy (where the code actually came from) the type T
isn't accessible where the kind of h%x(something)%v is needed.  If I
bring it into scope, I suppose I could create a scalar temp of the same
type as h%x just to be able to access kind(temp%v).  In the real world,
the temp would be a bigger thing-o, not just one pointer component.

An alternative is to declare a parameter to use to specify the kind of V
components of objects of type T, in the module where T is defined, and
access that parameter by use association where I need the kind of h%

I was hoping for something simpler.

> The subscript "I" in the expression is not itself an initialization expression 
> so it violates this requirement.
> The presence of intrinsic functions such as LEN and SIZE in the list of 
> permitted inquiries makes it easy to see why this requirement exists.

I don't see why SIZE or LEN (or LBOUND or UBOUND or a length parameter
inquiry) makes this necessary.  One only needs to access the i'th
element of the object to get SIZE or LEN if it might be different in
each array element, and that can only happen if the argument of SIZE or
LEN has a dimension or length that is defined by a length parameter that
is not a constant expression, or if it's allocatable or a pointer.  In
those cases, the "properties inquired about" are defined by an
expression that is not a constant expression.  Why prohibit the inquiry
in two independent ways?

> BTW, detection of the violation of the requirement is mandatory in the context 
> of the constraint for rule R730.
> Similar text and constraints exist in F2010.
> Cheers,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KindTest.f90
Type: text/x-fortran
Size: 434 bytes
Desc: not available
URL: <http://j3-fortran.org/pipermail/j3/attachments/20101110/c799072a/attachment.bin>

More information about the J3 mailing list