Hi Gary

Objects of derived type containing allocatable components can't appear in
built-in I/O regardless of definition status. As you found out, you can
just write the individual components instead of the containing structure.
If your compiler supports user-defined derived type I/O, you can specify
your own routine that will be called to do the write operation. Your
routine will most likely have to check the allocation status of each
allocatable component before writing it and also decide what to write if the
component is not allocated. Look up the write(formatted) and
write(unformatted) generic interfaces for more information.

Richard has already answered about the reasons for this constraint.

Regards

Rafik
Visit the Fortran Cafe at http://ibm.com/rational/cafe

"Gary Scott" <garylscott@sbcglobal.net> wrote in message
news:jknveh$af1$1@dont-email.me...
> On 3/25/2012 2:14 PM, Gary Scott wrote:
>> On 3/25/2012 2:13 PM, Gary Scott wrote:
>>> On 3/25/2012 11:37 AM, Richard Maine wrote:
>>>> Gary L. Scott<garylscott@sbcglobal.net> wrote:
>>>>
>>>>> If I have a sequence derived type with say two allocatable components,
>>>>> does it matter the order that I allocate the components?
>>>>
>>>> No.
>>>>
>>>>> Is it
>>>>> essentially "undefined" until I allocate the final component?
>>>
>>> I was wondering because I wanted to use the first two static components
>>> to read a file and assign to them "record type" and number of elements
>>> to be allocated. I guess I should read into static variables and not
>>> make assignment to the DT until after the allocation is complete. (just
>>> trying to reduce # of local variables).
>>
>> It actually appears to be working as designed though...
>
> except for:
>
> Error 1 error #7822: Variables containing ultimate allocatable array
> components are forbidden from appearing directly in input/output lists.
>
> Why this restriction if I have previously fully allocated all components
> to match the file content?
>
>>
>>>
>>>>
>>>> Hmm. That's a slightly subtle point, which drove me to check some
>>>> details. I'm not sure the standard is 100% consistent on this, though I
>>>> didn't spend enough time to be sure of that. The standard does say that
>>>> a derived type object is defined if each non-pointer component is
>>>> defined. An allocatable is not a pointer (its implementation in memory
>>>> might look like one, but that's irrelevant). An unallocated allocatable
>>>> is undefined. Thus, that would support your statement above that the
>>>> derived-type object is undefined as long as either of the allocatable
>>>> components are unallocated.
>>>>
>>>> But you can do intrinsic assignment of a derived type object that has
>>>> unallocated components. The standard explicitly describes what happens
>>>> in that case (and it is the "obvious" thing - that the variable
>>>> assigned
>>>> to will end up with the corresponding component unallocated).
>>>>
>>>> Hmm. Gotta go. I think I might recall that the requirement fo rthe RHS
>>>> of an assignment be defined might not apply to derived types, but I
>>>> don't have time to check that. Breakfast call from wife.
>>>>
>>>
>>
>