【问题标题】:How to access (dynamically allocated) Fortran arrays in C如何在 C 中访问(动态分配的)Fortran 数组
【发布时间】:2012-08-13 13:04:23
【问题描述】:

我的主要问题是为什么数组会做如此奇怪的事情,以及是否有任何方法可以以“干净”的方式执行以下操作。

我目前有一个 C 程序 foo.c 通过 dlopen/dlsym 连接一个 Fortran 程序 bar.f90,大致类似于下面的代码:

foo.c:

#include <dlfcn.h>
#include <stdio.h>

int main()
{
int i, k = 4;
double arr[k];
char * e;

void * bar = dlopen("Code/Test/bar.so", RTLD_NOW | RTLD_LOCAL);

void (*allocArray)(int*);
*(void **)(&allocArray) = dlsym(bar, "__bar_MOD_allocarray");
void (*fillArray)(double*);
*(void **)(&fillArray) = dlsym(bar, "__bar_MOD_fillarray");
void (*printArray)(void);
*(void **)(&printArray) = dlsym(bar, "__bar_MOD_printarray");
double *a = (double*)dlsym(bar, "__bar_MOD_a");

for(i = 0; i < k; i++)
    arr[i] = i * 3.14;

(*allocArray)(&k);
(*fillArray)(arr);
(*printArray)();
for(i = 0; i < 4; i++)
    printf("%f ", a[i]);
printf("\n");

return 0;
}

bar.f90:

module bar

integer, parameter :: pa = selected_real_kind(15, 307)
real(pa), dimension(:), allocatable :: a
integer :: as

contains

subroutine allocArray(asize)
    integer, intent(in) :: asize

    as = asize
    allocate(a(asize))

    return
end subroutine

subroutine fillArray(values)
    real(pa), dimension(as), intent(in) :: values

    a = values
    return
end subroutine

subroutine printArray()
    write(*,*) a
    return
end subroutine

end module

运行主产量

0.0000000000000000        3.1400000000000001        6.2800000000000002        9.4199999999999999     
0.000000 -nan 0.000000 0.000000 

这表明 Fortran 正确地分配了数组,甚至正确地存储了给定的值,但它们不再可以通过 dlsym 访问(处理该数据会导致段错误)。我也对固定大小的数组进行了尝试 - 结果保持不变。

有人知道这种行为的原因吗?就我个人而言,我希望事情要么双向解决,要么根本不解决——这个“Fortran 接受 C 数组,但反之不行”让我想知道我在以这种方式从 C 访问数组时是否犯了一些基本错误。

另一个(甚至更重要的)问题是,如何以“正确的方式”进行数组访问。目前我什至不确定坚持“Fortran as .so”界面是否是一个好方法——我认为在这种情况下也可以尝试混合编程。尽管如此,数组问题仍然存在 - 我读到这可以使用 ISO C 绑定以某种方式解决,但我不知道如何解决(我还没有使用 Fortran 进行很多工作,尤其是没有使用所述绑定) ,因此非常感谢您对此问题的帮助。

编辑:

好的,所以我进一步阅读了 ISO C 绑定,发现了一个非常有用的方法here。使用 C_LOC 我可以获得指向我的 Fortran 结构的 C 指针。不幸的是,指向数组的指针似乎是指向指针的指针,需要在 C 代码中取消引用,然后才能将它们视为 C 数组 - 或类似的东西。

编辑:

让我的程序现在可以按照 Vladimir F 指出的方式使用 C 绑定运行,至少在大多数情况下如此。 C 文件和 Fortran 文件现在链接在一起,因此我可以避免使用 libdl 接口,至少对于 Fortran 部分而言 - 我仍然需要加载动态 C 库,获取指向其中一个符号的函数指针并传递它作为指向 Fortran 的函数指针,后者随后将该函数作为其计算的一部分调用。正如所说的函数需要 double*s [arrays],奇怪的是,我无法使用 C_LOC 传递我的 Fortran 数组 - C_LOC(array)C_LOC(array(1)) 都没有将正确的指针传递回 C 函数。 array(1) 做到了。可悲的是,这不是做到这一点的“最干净”的方式。如果有人提示我如何使用C_LOC 函数来做到这一点,那就太好了。尽管如此,我还是接受 Vladimir F 的回答,因为我认为这是更安全的解决方案。

【问题讨论】:

  • 你绝对应该使用 ISO_C_BINDING,这个网站上有很多关于这个的问题和答案
  • 您通常不使用 C_LOC 和 C_PTR 传递数组(如果是,则使用 VALUE!),而是直接传递(对于 bind(C) 过程,Fortran 是通过引用传递)。

标签: c fortran dlsym fortran2003 fortran-iso-c-binding


【解决方案1】:

许多 Fortran 编译器在内部使用称为数组描述符的东西 - 保存数组形状的结构(即每个维度的大小和范围以及指向真实数据的指针)。它允许实现诸如假定形状数组参数、数组指针和可分配数组之类的工作。您通过__bar_MOD_a 符号访问的是可分配数组的描述符,而不是其数据。

数组描述符是特定于编译器的,依赖于特定描述符格式的代码是不可移植的。示例描述符:

请注意,即使是那些特定于这些编译器的某些版本的。例如,英特尔声明他们当前的描述符格式与英特尔 Fortran 7.0 中使用的格式不兼容。

如果您查看这两个描述符,您会发现它们非常相似,并且第一个元素是指向数组数据的指针。因此,您可以使用double ** 而不是double * 轻松读取数据:

double **a_descr = (double**)dlsym(bar, "__bar_MOD_a");
...
for(i = 0; i < 4; i++)
    printf("%f ", (*a_descr)[i]);

再一次,这是不可移植的,因为这些描述符的格式将来可能会改变(尽管我怀疑数据指针会被移动到描述符开头之外的其他地方)。有一个规范草案试图统一所有描述符格式,但不清楚不同编译器供应商将如何以及何时采用它。

编辑:以下是如何使用访问器函数,该访问器函数使用来自ISO_C_BINDING 模块的C_LOC() 可移植地获取指向可分配数组的指针:

Fortran 代码:

module bar
  use iso_c_binding
  ...
  ! Note that the array should be a pointer target
  real(pa), dimension(:), allocatable, target :: a
  ...
contains
  ...

  function getArrayPtr() result(cptr)
    type(c_ptr) :: cptr

    cptr = c_loc(a)
  end function

end module

C 代码:

...
void * (*getArrayPtr)(void);
*(void **)(&getArrayPtr) = dlsym(bar, "__bar_MOD_getarrayptr");
...
double *a = (*getArrayPtr)();
for(i = 0; i < 4; i++)
    printf("%f ", a[i]);
...

结果:

$ ./prog.x
   0.0000000000000000        3.1400000000000001        6.2800000000000002
 9.4199999999999999
0.000000 3.140000 6.280000 9.420000

【讨论】:

  • 你绝对应该使用 ISO_C_BINDING。
  • 好吧,如果你打赌N1904关于数组描述符的草案规范迟早会被采用,那么你可以通过开头的指针访问数据。否则你最好定义访问子程序/函数。
  • @HighPerformanceMark,正确。我已经改写了这一段。 ISO/IEC 1539-1:2010 的注释 15.16 还明确指出可分配数组不能与 C 互操作。然而“Fortran 与 C 的进一步互操作性”N1917 试图公开此实现细节以提供反向互操作性(例如访问来自 C) 的 Fortran 对象。
【解决方案2】:

在我看来,尝试访问 Fortran 库中的全局数据并不是一个好习惯。它可以使用 COMMON 块来完成,但它们是邪恶的并且需要静态大小的数组。一般来说,存储关联是一件坏事。

永远不要以“__bar_MOD_a”的形式访问模块符号,它们是编译器特定的,不能直接使用。使用函数和子例程传递指针。

将数组作为子例程参数传递。您还可以在 C 中分配数组并将其传递给 Fortran。还可以做的是获取指向数组第一个元素的指针。它将提供指向数组的 C 指针。

我的解决方案,为了简单起见,没有.so,添加它很简单:

bar.f90

module bar
 use iso_C_binding

implicit none

integer, parameter :: pa = selected_real_kind(15, 307)

real(pa), dimension(:), allocatable,target :: a
integer :: as

contains

subroutine allocArray(asize,ptr) bind(C,name="allocArray")
    integer, intent(in) :: asize
    type(c_ptr),intent(out) :: ptr

    as = asize
    allocate(a(asize))

    ptr = c_loc(a(1))
end subroutine

subroutine fillArray(values) bind(C,name="fillArray")
    real(pa), dimension(as), intent(in) :: values

    a = values
end subroutine

subroutine printArray()  bind(C,name="printArray")

    write(*,*) a
end subroutine

end module

main.c

#include <dlfcn.h>
#include <stdio.h>

int main()
{
int i, k = 4;
double arr[k];
char * e;
double *a;
void allocArray(int*,double**);
void fillArray(double*);
void allocArray();


for(i = 0; i < k; i++)
    arr[i] = i * 3.14;

allocArray(&k,&a);
fillArray(arr);
printArray();
for(i = 0; i < 4; i++)
    printf("%f ", a[i]);
printf("\n");

return 0;
}

编译运行:

gcc -c -g main.c

gfortran -c -g -fcheck=all bar.f90

gfortran main.o bar.o

./a.out
0.0000000000000000        3.1400000000000001        6.2800000000000002        9.4199999999999999     
0.000000 3.140000 6.280000 9.420000 

注意:您的 Fortran 子例程中没有返回的原因,它们只会使代码变得模糊。

【讨论】:

  • 可以使用模块变量和 ISO C 绑定在 Fortran 和 C 之间共享全局数据。
  • 是的,我有一段时间在考虑这个解决方案。第一段具有误导性,因为它可能暗示 COMMON 是唯一的方法。我通常根本不喜欢共享全局数据,并且更喜欢 allocData 不分配全局数组,而是分配一个指针数组并返回一个指向它的 c 指针。然后 C 程序会将指针传递给子例程。
  • 您通常不关心 Fortran 符号。您必须使用 iso_C_binding 然后每个可互操作的函数或变量与您声明的绑定将获得您请求的符号。我主张不绑定全局符号,而是传递指针 (c_ptr) 或使用虚拟参数。访问 Fortran 名称损坏的符号几乎总是一个坏主意。
猜你喜欢
  • 2014-01-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-05-07
  • 2022-01-17
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多