Re: allocatable components and TRANSFER behavior

glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx> wrote:

Richard Maine <nospam@xxxxxxxxxxxxx> wrote:

No. Its a bit tricky to work through the exact words that say no, but
I'm convinced they are there. Transfer is just about copying bits.
Automagic allocation is not just copying bits.

It doesn't seem so obvious to me. Separate from the copy bits
question, allocate on assignment (that is what I thought was
being asked) is a property of the assignment. How about:

v2 = transfer(tempv, v1) + 1

Now the expression has to be evaluated before the assignment.

It has nothing to do with the assignment. The transfer itself is what
has the problem. And, as usual, you are thinking to much about
implementation issues. This is most definitely a question about the
standard - not about what an implementation is likely to do. As
described by the standard, the RHS is *ALWAYS* evaluated before the
assignment. Anything ese is an optimization. While your +1 might change
the odds of an implementation optimizing things, it does not change what
the standard says about it.

The transfer itself gives a copy of the "physical representation". The
descriptor is part of that physical representation". If the transfer
allocated memory elsewhere and made the descriptor point to that new
memory, then the result would not have the same physical representation.
See also the description of what happens to allocatable components of
function results. They are deallocated after the statement completes.
That's going to be a problem here.

Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain