From owner-sc22wg5@open-std.org Sat Mar 28 13:34:52 2009 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 9CA4FC76BB3; Sat, 28 Mar 2009 13:34:52 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 826 seconds by postgrey-1.18 at www2.open-std.org; Sat, 28 Mar 2009 13:34:51 CET Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by www2.open-std.org (Postfix) with ESMTP id 3A641C56D20 for ; Sat, 28 Mar 2009 13:34:39 +0100 (CET) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2SCKcdH017490 for ; Sat, 28 Mar 2009 05:20:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=us-ascii Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH700200TY2NV00@fe-sfbay-10.sun.com> for sc22wg5@open-std.org; Sat, 28 Mar 2009 05:20:38 -0700 (PDT) Received: from [129.146.84.104] ([unknown] [129.146.84.104]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH700ELTUADZVF0@fe-sfbay-10.sun.com>; Sat, 28 Mar 2009 05:20:37 -0700 (PDT) Date: Sat, 28 Mar 2009 05:20:37 -0700 From: Robert Corbett Subject: Re: (j3.2006) (SC22WG5.3966) question about deallocation In-reply-to: <20090328111654.751BFC56D20@www2.open-std.org> To: fortran standards email list for J3 Cc: WG5 Reply-To: Robert.Corbett@Sun.COM Message-id: <49CE1615.70702@sun.com> Organization: Sun Microsystems, Inc. X-Accept-Language: en-us, en References: <49CACA36.5070104@nag-j.co.jp> <49CDEC08.8040403@sun.com> <20090328111654.751BFC56D20@www2.open-std.org> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Sender: owner-sc22wg5@open-std.org Precedence: bulk Reinhold Bader wrote: > Hello, > > Robert Corbett schrieb: > >>Consider the code fragment >> >> MODULE M >> . . . >> TYPE BASE >> INTEGER I >> CONTAINS >> FINAL SUBR1 >> END TYPE >> TYPE, EXTENDS(BASE) :: EXTENDED >> CONTAINS >> FINAL SUBR2 >> END TYPE >> . . . >> END MODULE >> >> PROGRAM MAIN >> USE M >> TYPE(EXTENDED), POINTER :: P >> TYPE(BASE), POINTER :: Q >> . . . >> ALLOCATE(P) >> Q => P%BASE >> . . . >> DEALLOCATE(Q) >> . . . >> END >> >>Is the DEALLOCATE statement standard conforming? > > I think it isn't. Clause 6.3.3.2 of the 2003 standard says that > > "If a pointer appears in a DEALLOCATE statement, it shall be associated > with the whole of an object > that was created by allocation." > > Surely this rule is also applicable for the case of type extension. It is not clear to me what constitutes "the whole of an object." Even before the addition of the object-oriented features, it was unclear. I was surprised when I was told that the code REAL, DIMENSION(:), POINTER :: P REAL, POINTER :: Q ALLOCATE(P(1)) Q => P(1) DEALLOCATE(Q) was standard conforming. The logic was that the storage referenced by Q includes all of the storage allocated for P. In my example also, the storage referenced by Q includes all of the storage allocated for P, and so the same logic might apply. Or, it might not. If my example code is not standard-conforming, it is harder to use polymorphism to effectively implement discriminated unions than some have claimed. If it is standard conforming, the rules for applying finalizers are unclear at best and broken at worst. Bob Corbett > Regards > >> If so, >>are both final subroutines invoked, or is only SUBR1 >>invoked? The implementation of deallocation in Sun >>Fortran can easily be extended to support either >>semantics. >> >>Bob Corbett >>_______________________________________________ >>J3 mailing list >>J3@j3-fortran.org >>http://j3-fortran.org/mailman/listinfo/j3 >> > > > _______________________________________________ > J3 mailing list > J3@j3-fortran.org > http://j3-fortran.org/mailman/listinfo/j3