使用 move_alloc 和源分配扩展可分配数组

Question

在下面的代码中，我试图增加a(:)的长度，首先分配一个更大的临时数组buf(:)，将a(:)的内容复制到buf(:)，然后使用move_alloc()将数组描述符从buf 复制到a：

program main
    implicit none
    integer, allocatable :: a(:), buf(:)

    allocate( a(2) )
    a = [1,2]

    allocate( buf( 4 ), source= 0 )     !! (1)
    buf( 1:2 ) = a( 1:2 )               !! (2)

    ! allocate( buf( 4 ), source= a )   !! (3)

    ! deallocate( a )                   !! (4)
    call move_alloc( buf, a )

    print *, "a(:) = ", a(:)
end

在这里，我有两个问题：首先，在第 4 行中，是否有必要在调用 move_alloc() 之前显式释放 a(:)...？即使没有第 4 行，gfortran 和 Intel Fortran 似乎都可以工作，但这是否意味着 move_alloc() 自动解除分配 a(:) 如果它是预先分配的？其次，我们能否将第 1 行和第 2 行替换为 3，即，对不同长度的数组使用源分配？我已经对此进行了试验，而且 gfortran 和 Intel Fortran 似乎都接受了它并获得了（显然）正确的结果。

Answer 1

从 Fortran 标准 (2008, 13.7.118) 关于 move_alloc 我们有参数 to 的详细信息（子例程的第二个参数）

这是一个意图（OUT）参数

与您在 gfortran manual 的链接中给出的描述相匹配。

对于任何其他具有intent(out) 和allocatable 属性的虚拟参数，与to 关联的实际参数在调用子例程move_alloc 时被释放。也就是说，您不需要自己解除分配a。

关于源分配，我们already know表示被分配的数组必须与源数组一致，这样才能写

allocate(buf(4), source=a)  ! a is the same rank as buf, but extent 2

无效，和

一样

allocate(buf(4), source=a(1:2))

是。

然而，虽然有一些关于来源分配的编号限制，但这种符合要求的要求并不包含在其中之一中。因此，您的编译器不需要检测您的代码是否不合格。

当然，编译器允许抱怨，正如您在使用a(1:2) 作为源代码时看到的那样。在某种程度上，在编译时更容易看到范围为 4 的数组与a(1:2) 不一致，而不是a。您可以使用 a(1:SIZE(a)) 进行试验，看看您的编译器在进行此类测试时付出了多少努力。

作为最后的评论，当然可以用单一来源的分配替换您的第 1 行和第 2 行：

allocate(buf, source=[a,0,0])  ! Buf is 2 longer than a

但这并不一定是“更好”。

Answer 2

Fortran 标准的编写使您不必担心可分配的内存泄漏。如果操作不是一开始就禁止的，则不应造成任何泄漏。此规则适用于任何可能的符合标准且具有可分配变量的操作。

因此，正如英特尔手册所述，to 参数将首先被释放。

Answer 3

是否需要解除分配a(:):

更新我误读了你的问题。您在询问TO 部分。

我刚刚用valgrind 进行了尝试，似乎deallocate 不是防止泄漏所必需的。但我可能还是会这样做，只是为了安全起见。

第二个问题：

[我们可以] ...对不同长度的数组使用源分配吗？

根据我信任的Fortran Book，没有：

[The] ... 分配的数组必须与源数组或表达式一致（具有相同的秩和形状）。

再说一次，我的书没有涵盖 2003 年以后的标准，因此 Fortran 2008 或 Fortran 2015 的情况可能会有所不同。