7.1 调用C与Fortran代码

7.1 调用 C 代码（C/Fortran）

@ccall 是 Julia 与机器码之间的直达通道：声明函数签名，其余交给编译器，无包装层、无数据序列化。LAPACK、BLAS 这些数值基石在 Julia 内部正是这样被调用的。

最小例子：调 C 标准库的数学函数

不写一行 C 代码，直接调 libc 里的 cos：

x = @ccall libc.cos(x::Cdouble)::Cdouble
​

读法：库名.函数名(参数::C类型)::返回C类型。C 的 double 对应 Cdouble，int 对应 Cint，映射表是机械翻译。

完整流程：调一个自己编译的共享库

假设有一段 C 代码编译成了共享库（内容：向量放缩与点积）。Julia 侧：

# scale：把长度 n 的数组每个元素乘以 a
function c_scale!(v::Vector{Float64}, a::Float64)
    @ccall "./libvec.so".scale(
        v::Ptr{Cdouble},        # 数组退化为指针
        a::Cdouble,
        length(v)::Csize_t,
    )::Cvoid
    return v
end

v = [1.0, 2.0, 3.0]
c_scale!(v, 2.0)      # v 变为 [2.0, 4.0, 6.0]，原地修改
​

Julia 类型与 C 类型的对照

调用链路：无转换直达

Fortran 库：注意参数顺序与引用传递

Fortran 参数全部按引用传递，且数组是列主序。调 LAPACK 风格函数时签名里全用 Ptr：

# 概念示意：Fortran 例程参数都要传指针，返回值通常写在参数里
@ccall libfort.dosomething(n::Ref{Cint}, x::Ptr{Cdouble}))::Cvoid
​

标量传引用用 Ref。另外 Julia 数组天然列主序，与 Fortran 一致——这是历史合作的巧合红利，与 C 交互时反而要小心行主序差异。

⚠️ 常见坑：传字符串给 C 前用 Base.cstring 或 Cstring 转换；传 Vector{Real} 之类的抽象类型数组给 Ptr{Cdouble} 会失败——数组元素类型必须具体且匹配。

💡 关键直觉：看到某个 Julia 包"没用绑定就调了老库"，底层几乎都是 @ccall。会读它，你就能给任何无主的 C 库自己写一层 Julia 接口。

案例：给一个 C 数值库手写 Julia 绑定

背景：课题组有一个编译好的 C 库，实现了某种特殊滤波，只有 C 接口没有 Julia 包。目标是在 Julia 里像调普通函数一样用它。第一步，确认 C 侧签名（从头文件抄）：void filt(const double* in, double* out, int n, double alpha)。第二步，写 Julia 包装层并处理内存：

function c_filt(v::Vector{Float64}, alpha::Float64)
    out = similar(v)                 # 预分配输出，尺寸与输入一致
    @ccall "./libfilt.so".filt(
        v::Ptr{Cdouble},
        out::Ptr{Cdouble},
        length(v)::Cint,
        alpha::Cdouble,
    )::Cvoid
    return out                        # out 被 C 侧原地写满，直接返回
end

x = rand(1000)
y = c_filt(x, 0.9)                    # Vector{Float64}，类型完整
​

操作要点有三：输出数组用 similar 在 Julia 侧分配，绝不把裸指针交给 C 去分配（谁来分配谁来释放，跨语言混管内存是崩溃之源）；length(v) 的类型转换在签名处完成；包装函数返回具体类型 Vector{Float64}，保持 2.1 强调的类型稳定。第三步验证正确性——用一组已知输入对比 C 程序直接跑的输出，逐位一致后绑定才算可用。变式：库若要求"调用方先初始化、退出时清理"，把初始化包进 __init__（3.2 讲过模块初始化钩子），清理挂到 atexit，一个工程级绑定就完成了。

排错现场：段错误与无声错误

C 调用的报错分两档。显性档是 signal (11) 段错误，REPL 直接崩，九成原因是签名写错——类型对不上、参数顺序错、或者该传长度的地方传了错误值；排查方法是把 C 侧签名逐字段抄进注释再对照 @ccall 一行行核对。隐性档更危险：C 侧越界写内存却不立刻崩，Julia 里表现为"数组莫名被改"或随机位置出错，根源多为长度参数与实际数组不符。防御手段是包装层加 @assert 校验长度与元素类型，把契约挡在 Julia 侧。另外调 C 前把 v = collect(v) 具体化（防止传入视图等非连续数组）、用 Base.unsafe_convert(Ptr{Cdouble}, v) 理解指针获取时机，都是读懂别人绑定时需要的背景。

本节要点回顾

• @ccall 库.函数(参数::C类型)::返回类型 一个语法解决全部 C 调用；
• 数组传 Ptr、标量传引用用 Ref、无返回用 Cvoid；
• Julia 数组列主序与 Fortran 一致、与 C 相反，交互前先想清布局；
• 零拷贝零包装，这条路也是理解 Julia 底层性能的窗户；
• 包装层要"Julia 侧分配、返回具体类型、入口断言契约"，让 C 的边界又薄又硬。

再补一个阅读线索：想深入看别人怎么写绑定，标准库里 Base.Math 与 LinearAlgebra.LAPACK 的源码就是最好的教材——几十行 @ccall 包装出整个 LAPACK 接口，读通一个文件，本章所有知识点都有了活样本。