Subject: MOVE_ALLOC Edits J3/03-162r2 From: Kurt W. Hirchert (Meeting 164) 03 Apr 2003 ===== Edits ===== All edits are expressed relative to J3/02-007r3: {* Much of 6.3.1.1 is "broken" in that it does not allow for the features added by the ALLOCATABLE TR, so some kind of repair would be needed there even if the rest of this paper is rejected. *} [110:24-25] Replace first sentence of the paragraph with "The status of an allocatable variable becomes <> if it is allocated by an ALLOCATE statement, if it is allocated during assignment, or if it is given that status by the allocation transfer procedure (13.5.15+1)." [111:2] After first sentence of the paragraph, insert "The status of an allocatable variable becomes unallocated if it is deallocated (6.3.3) or if it is given that status by an allocation transfer procedure." [111:4] After "argument", insert "corresponding to a nonallocatable dummy argument," [111:8-9] Replace last two sentences of paragraph with "The status may change during the execution of the program." {* Cf. 111:14 and 111:16 *} [287:15] "subroutine MVBITS is" -> "subroutines MOVE_ALLOC and MVBITS are" [287:15+1] After "The", insert "effects of MOVE_ALLOC are limited to its arguments. The remaining" [293:25+] Insert " 13.5.14+1 Allocation transfer procedures MOVE_ALLOC(FROM,TO) Transfers an allocation from one allocatable object to another" [332:28+] Insert text <<<<< 13.7.79+1 MOVE_ALLOC(FROM,TO) Description. Transfers an allocation from one allocatable object to another. Class. Subroutine. Arguments. FROM may be of any type and rank. It shall be allocatable. It is an INTENT(INOUT) argument. TO shall be type compatible (5.1.1.8) with FROM and have the same rank. It shall be allocatable. It shall be polymorphic if FROM is polymorphic. It is an INTENT(OUT) argument. Each nondeferred parameter of the declared type of TO shall have the same value as the corresponding parameter of the declared type of FROM. The allocation status of TO remains unallocated if FROM is unallocated on entry to MOVE_ALLOC. Otherwise, TO becomes allocated with dynamic type, type parameters, array bounds, and value identical to those that FROM had on entry to MOVE_ALLOC. If TO has the TARGET attribute, any pointer associated with FROM on entry to MOVE_ALLOC becomes correspondingly associated with TO. If TO does not have the TARGET attribute, the pointer association status of such a pointer becomes undefined. The allocation status of FROM becomes unallocated. Example. REAL,ALLOCATABLE :: GRID(:),TEMPGRID(:) ... ALLOCATE(GRID(-N:N) ! initial allocation of GRID ... ! "reallocation" of GRID to allow intermediate points ALLOCATE(TEMPGRID(-2*N:2*N)) ! allocate bigger grid TEMPGRID(::2)=GRID ! distribute values to new locations CALL MOVE_ALLOC(TO=GRID,FROM=TEMPGRID) ! old grid is deallocated because TO is ! INTENT(OUT), and GRID then "takes over" ! new grid allocation Note 13.14+1 It is expected that the implementation of allocatable objects will typically involve descriptors to locate the allocated storage; MOVE_ALLOC could then be implemented by transfering the contents of the descriptor for FROM to the descriptor for TO and clearing the descriptor for FROM. >>>>> [404:29+] Insert " (2+1) The allocation transfer procedure (13.5.15+1) is executed with an argument that is associated with the pointer, except under certain circumstances described in 13.7.79+1." [412:21+] Insert " (9+1) When the allocation transfer procedure (13.5.15+1) causes the allocation status of an allocatable entity to become unallocated, the entity becomes undefined." - end -