Fortran中元素子程序的复杂性 问题

将子例程标记为

元素

时是否存在任何复杂情况？似乎是这样，但没有详细说明它们可能是什么

注意：我之所以标记多个fortran版本，是因为我想知道在开发可移植代码时，这些版本之间是否存在差异

例子 假设我想编写一个元素子程序，在笛卡尔坐标系和极坐标系之间进行转换。这可以通过以下方式实现：

elemental subroutine calc_xy_from_rt( r, t, x, y )
    real*8, intent(IN)  :: r   ! radius
    real*8, intent(IN)  :: t   ! theta
    real*8, intent(OUT) :: x
    real*8, intent(OUT) :: y
    x = r * cos(t)
    y = r * sin(t)
end subroutine calc_xy_from_rt

因为它是基本的，所以可以在以下上下文中调用它：

program main
    implicit none

    real*8, dimension(1:100) :: r
    real*8, dimension(1:100) :: t
    real*8, dimension(1:100) :: x
    real*8, dimension(1:100) :: y

    ! (Initialize r and t arrays here)

    ! Calculate x and y for each element
    call calc_xy_from_rt( r, t, x, y )   ! gets called 100 times
end program main

---

我猜这个简单的过程不会有副作用，但我提供了一个例子，使讨论具体化，并提供一个可以扩展的MWE，以说明可能的副作用

元素子例程的明显复杂性是所有伪参数都必须是标量。有时，人们希望元素操作能够访问共享数组：这不能通过参数实现

此外，如果一个基本子例程是纯的，它将受到来自该性质的所有限制

无论是纯的还是非纯的，基本子例程都受到进一步的约束：

• 伪参数不能是指针或可分配的
• 伪参数不能是协阵
• 伪参数必须是数据对象

至于这些限制如何随时间和实现而变化，则无需担心

在Fortran 2008之前，所有基本子程序都是纯的，禁止使用coarray伪参数是毫无意义的

此外，编译器必须能够检测到违反这些限制的情况，我不知道有任何扩展会放宽这些限制

---

最后，当基本过程出现的时候，许多年前就出现了各种各样的编译器错误。人们不必太担心这些，除非捡起在叔公车库里找到的机器。

你说的“并发症”是什么意思？某些限制适用于基本子例程，而不适用于非基本子例程。你想知道这些吗？是的，没错。我不知道我不知道什么。这一联系表明它比表面上看起来更复杂。