Question on MOVE_ALLOC
Eric Kostelich
will code like the following populate B with the all the same
data as A and deallocate all the members of A as well as
A itself?
type t
real, allocatable:: member(:)
...
end type t
type(t), allocatable:: a(:), b(:)
! allocate and populate A
...
call move_alloc(a,b)
--Eric
Richard Maine
No. That's not the way it works. The effect is somewhat like that, but
not quite. Sounds to me like you have the wrong model for what is going
on.
Data is not copied at all, deep or otherwise. Conceptually, there are 3
steps.
1. First, if b was previously allocated, it is deallocated. That
includes all the usual consequences of any deallocation. Any allocatable
components would get deallocated, any applicable final procedures would
be executed, etc.
2. The allocation of A is moved to B. Note the word "moved". This is not
a copy operation at all. As the note in the standard explains, the
likely implementation will be that the descriptor is copied. The data
will not be copied, deep or otherwise. If the data were copied, first
that would be inefficient. A large part of the idea of move_alloc was to
lower the number of data copies required to do things like reallocation;
implementing it by copying data would negate the purpose. Also,
implementing it by copying would invalidate any pointers to the data;
the standard requires that such pointers remain valid (if B also has the
TARGET attribute).
3. Finally A is set to be deallocated. This will not involve actually
deallocating anything. All the contents got moved to B instead of
deallocated. This is just setting the top-level status of A to
deallocated.
Thus, nothing is ever allocated. Nowhere in the above steps is there a
new allocation of anything.
And the only thing that might get deallocated is any prior contents of
B; that's B - not A.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Eric Kostelich
> 3. Finally A is set to be deallocated. This will not involve actually
> deallocating anything. All the contents got moved to B instead of
> deallocated. This is just setting the top-level status of A to
> deallocated.
>
> Thus, nothing is ever allocated. Nowhere in the above steps is there a
> new allocation of anything.
Richard,
Thank you for your response. Just so I'm clear on this: Will the
call
to MOVE_ALLOC(A,B) move the allocation of A(K)%MEMBER to B(K)%MEMBER
for each valid index K of the original A? In other words, it is not
necessary to include code like
do k=1,n
call move_alloc(a(k)%member, b(k)%member)
enddo
Thanks,
--Eric
Richard Maine
> On Jul 1, 12:55 pm, nos...@see.signature (Richard Maine) wrote:
>
> > 3. Finally A is set to be deallocated. This will not involve actually
> > deallocating anything. All the contents got moved to B instead of
> > deallocated. This is just setting the top-level status of A to
> > deallocated.
> >
> > Thus, nothing is ever allocated. Nowhere in the above steps is there a
> > new allocation of anything.
>
> Thank you for your response. Just so I'm clear on this: Will the
> call
> to MOVE_ALLOC(A,B) move the allocation of A(K)%MEMBER to B(K)%MEMBER
> for each valid index K of the original A? In other words, it is not
> necessary to include code like
>
> do k=1,n
> call move_alloc(a(k)%member, b(k)%member)
> enddo
It will have that kind of effect, but it isn't as though the
implementation actually has to do anything for that. That will just be
the effect of moving the top-level allocation. I'm still feeling that I
haven't managed to communicate what is happening. When you move the
allocation, that has the effect of moving everything, without actually
doing any copying. It is much like renaming; that stuff which was
formerly A is now B. "That stuff" includes everything under it. I could
say that in more technical terms, which would make it sound much more
esoteric, but the essense is the same.
Not only is it not necessary to include code like that, there are no
situations in which it would be valid. If you have already done the
move_alloc from A to B, there won't still be an A(K) to reference. If
you haven't yet done the move_alloc, then there might or might not be a
B(K), but even if there is, doing this followed by a move_alloc or A to
B would destroy the data.