(j3.2006) Did we intend to prohibit this?
Fri Mar 10 19:19:27 EST 2017
On Fri, 2017-03-10 at 23:59 +0000, Bill Long wrote:
> On Mar 10, 2017, at 5:17 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> > On Fri, 2017-03-10 at 17:12 -0500, Steve Lionel wrote:
> >> On 3/10/2017 5:00 PM, Van Snyder wrote:
> >>> According to 220.127.116.11p4, whatever the function result is, it must be
> >>> allocatable, or it couldn't be deallocated.
> >> The difference is that the programmer is not in control of the
> >> allocatable object once the function returns. As Tom says, you can see
> >> the value, but don't have a handle on the allocation. The processor is
> >> responsible for setting up the result variable as allocatable and
> >> deallocating it when the statement completes. You don't get to do
> >> anything to its allocation status or even reference it as if it were an
> >> allocatable.
> >> As Malcolm wrote, the purpose of this feature is to allow a function to
> >> return an arbitrary-shape result, the shape of which is then used in the
> >> context of the function's value. Once the function returns, the fact
> >> that the result is allocatable is invisible to the programmer.
> > I wasn't able to deduce any of this from the standard. The standard
> > natters on about deallocating an allocatable function result as if it
> > actually is allocatable.
> There is a local variable in the function that is the function result
> variable. If that is declared allocatable, then that variable is what
> gets deallocated. The result of the function is a value. Values are
> not deallocated, as they can?t have the allocatable attribute. I
> don?t think it is any more complicated that that.
18.104.22.168p4 disagrees with this analysis:
If an executable construct references a function whose result is
allocatable or has an allocatable subobject, and the function
reference is executed, an allocatable result and any allocated
allocatable subobject of the result is deallocated after
execution of the innermost executable construct containing the
> >> Steve
> >> _______________________________________________
> >> J3 mailing list
> >> J3 at mailman.j3-fortran.org
> >> http://mailman.j3-fortran.org/mailman/listinfo/j3
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> Bill Long longb at cray.com
> Fortran Technical Support & voice: 651-605-9024
> Bioinformatics Software Development fax: 651-605-9142
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
More information about the J3