(j3.2006) Why did we do this?

[Bill Long]

On 7/5/11 12:44 AM, Van Snyder 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."
>

This citation is qualified as being for unformatted I/O.  For that case, 
you want the I/O to occur as a block memory transfer with the length of 
a variable of the derived type. Much more efficient that way.  However, 
the values of allocatable and pointer components are not actually part 
of the memory block for the derived-type variable - just the dope 
vectors for these objects are part of the struct.  The actual data is 
elsewhere (target of the pointer, or the allocated data).  The current 
rules allow for a straightforward and efficient implementation.   If, 
for example, pointers were allowed, then you would need to somehow save 
some kind of link on output, and keep track of which target data was 
written where in the file. For input, you would need to create new base 
addresses for the dope vectors in the main struct, allocate new memory 
for the targets, and read them back in.  Or did you mean for the read 
operation of overwrite the old target in memory (which would work only 
if you read back in something that had been written out from the same 
program context, so the memory was still allocated at the same address)? 
  It would seem the possibility of undefined behavior is large here, and 
a lot of disagreement about what really is the desired behavior.    It's 
more reliable and predictable to have the user either treat the pointer 
component as a separate object in an expanded list, or to use a defined 
I/O procedure.

The same basic issues apply to formatted I/O, though the performance 
part of the argument is weaker there.

Cheers,
Bill

> 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

-- 
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