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