(j3.2006) Finalization ordering question
Wed Oct 24 16:04:23 EDT 2007
Jim Xia wrote:
> j3-bounces at j3-fortran.org wrote on 10/24/2007 02:38:05 PM:
> > On Wednesday 24 October 2007 11:29, Jim Xia wrote:
> > > Can you point out to me where in F2003 standard there is a
> reference to a
> > > parent component as an array?
> > Semantic issues asside, i.e., what "parent component of an entity
> that is an
> > array" means (Mike was also wondering this), I believe the intention
> here is
> > clear and in Interp would (should!) say: The parent component is
> finalized as
> > an array if an appropriate array finalizer exists.
> > This is the only thing that makes sense.
> Sorry to say I disagree here. I don't find this approach as the "only
> thing" that makes sense. In many cases, this approach is unnatural
> even with the argument of parent component(s) aside.
> First, for any extended type that has array finalizer, it requires its
> parent type to have the finalizer of the same rank. How often can you
> rely on this assumption for the finalization to be done correctly?
The parent is not required to have a finalizer of any particular rank.
If it happens to have one of the right rank, then Step 1 will result in
a final routine being called. Otherwise, you fall through to Step 2.
Same as starting with any entity at Step 1.
> Another problem is you're dealing with a non-contiguious array here in
> calling the parent's finalizer. Take Bill's example, X%T represents
> an array occupying non-contiguious spaces. Calling X's rank-one
> finalizer is great if the final subroutine is expecting an
> assumed-shape, then you can construct a descriptor and pass it to the
> routine. Well, what if the final subroutine is not expecting an
> assumed-shape, say assumed-size array instead, then you'll have make a
> copy of it and pass the address of the copy, and then copy back
> whatever is done to the original parent components. This is a classic
> copy-in/copy-out problem you'll be dealing with. I wouldn't count on
> a user to always use assumed-shape array in her array finalizer.
We already have the non-contiguous problem. Suppose the variable in an
intrinsic assignment is a rank-1 non-contiguous array section of a type
that has a rank-1 final routine specified. You will end up calling that
final routine with a non-contiguous argument. Effectively, an array
dummy argument in a final routine always needs to be assumed shape.
> In overall the scalar approach is much neutral in these situations
> even though it can't take advantage in the assumed-shape array case.
> In language design, I'd consider usability and safety first before
> considering performance issues.
If f03 had impure elementals, it might have made more sense for that to
be the only option. It would have simplified the rules. I think
performance is somewhat secondary here. People who write a bunch of
finalizers probably flunked out of (or never attended) performance
> Jim Xia
> XL Fortran Compiler Testing
> IBM Toronto Lab at 8200 Warden Ave.
> Phone (905) 413-3444 Tie-line 969-3444
> D2/NAH/8200 /MKM
> J3 mailing list
> J3 at j3-fortran.org
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3