(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