James Giles wrote:
> Nor do I think most implementations will maintain the distinction.
"Most" is irrelevant. Some do. Of the 4 compilers I have tested (NAG,
Intel, Lahey and Absoft), 3 maintain info in the array descriptor which
is tied to whether the given array was allocated with ALLOCATE. Some
maintain the actual allocation address and/or size, some just a bit
flag. But they DO!
> how would the memory
> manager even tell whether the pointer was assigned as with P
> above or as with Q?
As I explained above, it is in the descriptor, not in the memory
allocator itself.
> Are we to now require implementations
> to carry additional information internally that expresses that
> distinction, even though its only application is to confuse users?
We are not talking about requiring anything. We are talking whether they
are at all allowed to do such a thing. And they already DO, as I
explain above.
The way this works on current compilers, I would half guess, is that
when
p=>q
is compiled the whole dope vector is copied with all the bits in it,
while
p=>q(:)
would custom fill some fields, and would set the allocation bit to zero,
i.e., mark p as NOT ALLOCATED.
The way this came about was that I used to use POINTER arrays in some
data structures (OK, so you can see what I am working on), and now
changed to ALLOCATABLE. When one copies derived types via intrinsic
assignment a deep copy is done with allocatables, and this caused a
crash (thus the whole question of relocatable data structures).
Do compiler vendors have an arguement for their interpretation?
Aleks
|