(j3.2006) Why did we do this?

[Dick Hendrickson]

This came up on comp.lang.fortran a few weeks ago.  I think the answer
is that the allocatable or pointer elements don't have to be simple
things.  They can be derived types with allocatable or pointer
components.  Think about the pointer to the head of a linked list, or
worse, a circular list or tree.  You can do linked lists with either
pointer or allocatable components.  So, how does the processor know
when to stop expanding the pointer/allocatable thing into it's sub
parts?

Dick Hendrickson

On Tue, Jul 5, 2011 at 12:44 AM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
> [10-007r1:217:22] says "If an input or output item {in an I/O list} is
> allocatable it shall be allocated."
>
> [218:1-5] goes on "If an item of derived type ... the list item is treated
> as if all of the components of the object were specified in the list in
> component order; those components ... shall not be pointers or allocatable."
>
> If the program listed the components explicitly, the allocatable or pointer
> ones would be allowed. ?If the processor splits them out into components in
> component order, they're not allowed.
>
> Why did we do this?
>
> I do see a problem with I/O for derived type objects with allocatable
> pointer components, the problem being that the processor doesn't
> automatically split the object into its components if any of the components
> are pointer or allocatable. ?It only does this if any component would be
> processed by a defined I/O procedure.
>
> If objects of derived type were treated as a list of their components, in
> component order, if any of them are pointers or allocatable, the problem
> goes away?
>
> Why did we do this?
>
> We didn't prohibit objects of types with length components from appearing in
> I/O lists.
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>