Hi,

I've not been following this entire thread, so please forgive me
if I'm repeating (or even missing) one or more points made by
others.

On Wed, 21 Feb 2001, Van Snyder wrote:

> As has been pointed out, reallocation of a pointer is easier than
> reallocation of an allocatable, because there's one less copy.  The
> price is that the possibility of pointer aliasing typically turns
> off the optimizer.

Seems to me that the above is true only if you're working in
the context of F90 syntax.  With an intrinsic REALLOCATE, it
would be just as easy to REALLOCATE an ALLOCATABLE as a POINTER.

The real problem with REALLOCATE in F90, I believe, is the
semantics.  Suppose A is ALLOCATEed to A(3,2), and values are
assigned as follows:

        1 2
        3 4
        5 6

What would be the contents if A were REALLOCATEd to A(2,2)?  One
might like the answer to be:

        1 2
        3 4   ;

however, if A is in fact ALLOCATEd contiguously (which F90 doesn't
require, but which is likely), just trimming off the last two elements
(4,6) would in fact give

        1 5
        3 2   .

I would suggest, therefore, a limited REALLOCATE functionality
for Fortran.  Namely, a REALLOCATE that can be used to alter the
size of the last dimension, only.  This will always leave the
remainder of the array intact.

Thus, given A(3,2) with contents

        1 2
        3 4
        5 6   ,

REALLOCATE( A(2,2) ) would be illegal;  but REALLOCATE( A(3,1) )
would be legal, and would result in:

        1
        3
        5   .

Thus, any A(i,j) in the REALLOCATEd array would have the same
value as in the original array.

This also works with REALLOCATION to a larger size.  Given the
same initial A(3,2), REALLOCATE( A(4,2) ) would be illegal;
however, REALLOCATE( A(3,3) ) would be legal, and give:

        1 2 x
        3 4 x
        5 6 x   ,

where the x's indicate "junk" or unpredictable contents.  Then
any A(i,j) in the original array retains its value in the
REALLOCATEd array.

In my opinion, this restriction is entirely reasonable, and
this use of REALLOCATE in in fact the one most often met
in practice.  It would allow elimination of overallocation
and copying quite often, as in C.

I think few would argue that within the limited sphere defined
here, this REALLOCATE definition works exactly as (nearly)
everyone would desire.  A more general definition would take
years to agree upon (as we've seen :-) ), but that should not
stop us from accepting a narrower but better-defined proposal.

-P.