Cloning allocatable arrays in F95?

Hi,

while trying to clone an allocatable array, I found that ALLOCATE
appears to miss a useful feature.  It would be nice if the allocate-
shape-specification could also be an integer array of Rank 1.  Example:

! a, b, c have deferred shape
real, allocatable, dimension(:,:) :: a, b, c
integer :: i(2)

allocate (a(1,1))
print *, "shape(a) =", shape (a)

!allocate (b (shape (a)))   ! <- nice to have
allocate (b (size (a,dim=1), size (a,dim=2)))
print *, "shape(b) =", shape (b)

i(:) = shape (a)
!allocate (c(i(1:2)))       ! <- nice to have
allocate (c(i(1),i(2)))
print *, "shape(c) =", shape (c)

end


Note that in the allocation of array b the dimension of a is known and
verifyably agrees with that of b.  Similarly, the size of i and the
dimension of c.

Has this been considered before, and if it has been rejected, why?  Or
am I missing something?  (I am aware that non-default lower bounds
cannot be preserved that easily.)

--
Cheers,
-ha

Harald Anlauf <anlauf@hep.tu-darmstadt.de> writes:

> It would be nice if the allocate-
> shape-specification could also be an integer array of Rank 1.
....
> Has this been considered before, and if it has been rejected, why?

In short, yes, it has been considered. In fact, it has been considered
in more generality than that - namely for any context where one
specifies array bounds.  Automatic arrays come to mind. And
I even recall something about dealing with lower bounds - that's
certainly doable, perhaps with another such array.

As to why it got rejected, I'm afraid I just don't recall.  If you
wanted my best guess, it probably just didn't get enough support.
Enough things get proposed that they can't all be done, and it doesn't
actually take a concrete reason for something to fail.  Failure is
almost the default state, with active reason needed for things to
succeed.  Even things that most people like wil fail if they don't get
as much support as other things of comparable difficulty that people
like better.  This is just generalization, though.  I recall seeing
proposals in this area, but I don't recall anything about the votes
on them.

--
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

Richard E Maine wrote:

> Harald Anlauf <anlauf@hep.tu-darmstadt.de> writes:
 

(snip)

> In short, yes, it has been considered. In fact, it has been considered
> in more generality than that - namely for any context where one
> specifies array bounds.  Automatic arrays come to mind. And
> I even recall something about dealing with lower bounds - that's
> certainly doable, perhaps with another such array.

This is commonly done in C where the only dynamic allocation
method for higher than rank 1 is through arrays of pointers.
It is then easy to allocate the pointed-to arrays any desired
size.   There was a discussion before about arrays of pointers
in Fortran, but I don't remember the answer.

-- glen

Harald Anlauf wrote:
> Hi,
>
> while trying to clone an allocatable array, I found that ALLOCATE
> appears to miss a useful feature.  It would be nice if the allocate-
> shape-specification could also be an integer array of Rank 1.  Example:
>
> ! a, b, c have deferred shape
> real, allocatable, dimension(:,:) :: a, b, c
> integer :: i(2)
...
> allocate (a(1,1))
...
> !allocate (b (shape (a)))   ! <- nice to have

Or, possibly:

Allocate (b, mold=shape(a))

This follows precedent in the intrinsic functions.  And it would
allow several arrays to be allocated withthe same shape based on
one that already exists.

> !allocate (c(i(1:2)))       ! <- nice to have


Again, possibly:

Allocate(c, mold=i(1:2))

or, since I is only two elements anyway:

Allocate(c, mold=i)

This kind of addition wouldn't require as much effort as some completely
general way of subscripting arrays with arrays (something which already
has another meaning in some instances - vector subscripts).

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare