(j3.2006) Finalization ordering question

Bill Long longb
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 
school anyway.


> Cheers,
> 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
> http://j3-fortran.org/mailman/listinfo/j3

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 mailing list