(j3.2006) finalizing undefined entities

Jim Xia jimxia
Tue Mar 18 13:38:38 EDT 2008


For structures with only allocatable components, there is no need to 
provide finalizer because the compiler will automatically deallocate them. 
 For pointer components, this is essentially the same story as to C++ 
destructors for classes with pointer members.  Ultimately it is users' 
responsibility not to deallocate pointers that are not allowed to 
deallocate (same undefined behavior can result in C++ if you try to delete 
a pointer that points to an address not eligible for deletion).  It is not 
language's responsibility to define behavior for this case -- garbage in 
garbage out.

Cheers,

Jim Xia

RL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia at ca.ibm.com
D2/YF7/8200 /MKM



Michael Ingrassia <michaeli at ranma.sfbay.sun.com> 
Sent by: j3-bounces at j3-fortran.org
03/18/2008 01:21 PM
Please respond to
fortran standards email list for J3 <j3 at j3-fortran.org>


To
j3 at j3-fortran.org
cc

Subject
Re: (j3.2006) finalizing undefined entities






>I would expect to 
>see statements that begin IF (ALLOCATED( ... or IF (ASSOCIATED ( pretty 
>often in a robust final routine.

But  ASSOCIATED(X) has no semantics if the pointer association status
of X is undefined, right?  So it can't be used for this purpose.

I agree that ALLOCATED( ... can, but does that mean that programmers
are limited to finalizing 
allocatable entities if they want robust finalizers?
 
 
                 --Michael I.

 
_______________________________________________
J3 mailing list
J3 at j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20080318/dfc7c201/attachment.html 



More information about the J3 mailing list