TRANSFER and derived types, unrelated to floating point

Richard E Maine wrote:
(snip, mostly previously snipped)

> "Correct" isn't the right term here. Such behavior is allowed.
> It is not guaranteed.  Derived types don't *HAVE* to be laid out
> with internal structure the qay you might expect... and sometimes
> they aren't.  Your odds are probably good in the particular case
> you showed, but it is by no means guaranteed by the standard.

Continuing the discussion from yesterday, most likely a derived
type including an allocatable array actually includes a descriptor
to the array with a pointer to the allocated storage.  A copy
of such a type would then not include a copy of the allocated
storage.

> Yes, TRANSFER is one of the tools to use when you want to
> hack like that.  But, in addition my comment about dragons, I
> might summarize it by saying that if you have to ask, then you
> probably shouldn't be doing it.  :-(

I will then guess that TRANSFER does the copy of the derived type
data but not any storage for allocated arrays supported by
any extensions.  Also, would I/O of such derived types include
the allocated storage?

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Also, would I/O of such derived types include
> the allocated storage?

Ah.  I need to get back to other work, so I'm not going to check
the exact citation.  I might have the details wrong, but it is
probably something close to...

Unformatted I/O of derived types with allocatable components is not
allowed (unless done with a UDDTIOP, which avoids the issue), exactly
for this kind of reason. I'd have to look up formatted; it might
plausibly be ok for output... but I forget the exact conditions.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain