(j3.2006) Finalization ordering question
Wed Oct 24 15:15:07 EDT 2007
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
> > parent component as an array?
> Semantic issues asside, i.e., what "parent component of an entity that
> array" means (Mike was also wondering this), I believe the intention
> clear and in Interp would (should!) say: The parent component is
> 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?
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
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.
XL Fortran Compiler Testing
IBM Toronto Lab at 8200 Warden Ave.
Phone (905) 413-3444 Tie-line 969-3444
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3