Eigen是纯头文件模板库,无需链接;只需将include目录加入编译路径,如target_include_directories(... PUBLIC ${EIGEN3_INCLUDE_DIR})。
怎么确认 Eigen 是头文件库,不用链接
Eigen 不是传统意义上的动态或静态库,它压根没提供
或
文件。你看到的
能直接编译通过,是因为 Eigen 全是模板头文件——所有实现都在
里。编译器在实例化模板时才生成机器码。
所以:
不需要,也不用配
。常见错误是 CMake 里傻乎乎加
后又去 link,结果报
——那是因为你误以为它有符号要链接。
只要把 Eigen 的
目录加进编译器头文件搜索路径(CMake 用
)
确保
路径正确,比如
,不是
(除非你手动改了路径)
Mac 上用 Homebrew 装的 Eigen,默认头文件在
,别漏掉末尾的
MatrixXd 和 MatrixXf 到底该选哪个
类型选错最直接影响数值精度和运行时行为。Eigen 中矩阵类型由三部分决定:基类型(
/
)、行列数(
表示动态)、存储顺序(默认列优先)。别光看名字缩写,得盯住底层类型。
是
,
是
。两者内存布局一样,但浮点精度差一个数量级——
在求逆、SVD、共轭梯度等病态问题中容易溢出或丢失有效位。
立即学习
“
C++免费学习笔记(深入)
”;
科研计算、需要高精度中间结果(比如优化、PDE 离散),一律用
嵌入式或 GPU 前端预处理、对吞吐敏感且输入本身是
(如图像像素),可用
,但要自己验证误差是否可接受
混用会触发隐式转换:把
赋给
变量,编译不报错,但运行时多一次逐元素 cast,性能白丢
为什么 resize() 后数据没了,而 conservativeResize() 有时也不行
Eigen 默认不保留旧数据,这是为了明确语义:
就是“我要新尺寸”,不是“我打算扩/缩但留着原来那些”。很多人以为它像 Python 的
,结果发现原矩阵内容全变零。
C知道
CSDN推出的一款AI技术问答工具
下载
确实会尽量保留左上角子块,但它只在“新尺寸不小于旧尺寸”且“内存连续可延展”时才安全。比如从
扩到
成功;但从
缩回
,虽然能调用,但若原矩阵是表达式求值结果(如
),内部没有实际分配内存,就会 UB。
想保留数据,先用
,再用
显式拷贝
更稳妥的做法是:一开始就用
预分配,避免反复 resize
如果真要动态调整且频繁,考虑换
或用
包装外部缓冲区
用 Map 读原始数组时对齐失败就崩溃
默认要求指针对齐(16 字节对齐用于 SSE,32 字节用于 AVX)。如果你传进去的是普通
或栈上数组,大概率不对齐,运行时触发
或静默错误——尤其在开启
编译时。
根本原因:Eigen 在向量化路径里直接发
指令,该指令硬性要求地址对齐。不是所有平台都报错,但行为不可靠。
临时方案:构造
时加
标签,例如
长期方案:用
配合
,或直接用
(它内部自动处理对齐策略)
注意:
会降级为标量指令或非对齐向量指令,性能损失约 10%~30%,大数据量时得权衡
对齐这事看不见摸不着,但一旦出问题,core dump 里连函数名都可能被优化掉,查起来比维度错还费劲。
.so.lib#include .htarget_link_librariesLD_LIBRARY_PATHfind_package(Eigen3 REQUIRED)undefined referenceincludetarget_include_directories(... PUBLIC ${EIGEN3_INCLUDE_DIR})#include#include #include /opt/homebrew/include/eigen3eigen3doublefloatXMatrixXdMatrixMatrixXfMatrixfloatMatrixXdfloatMatrixXfMatrixXfMatrixXdresize()numpy.resizeconservativeResize()3x34x44x43x3A + Bresize().block(0,0,old_rows,old_cols) = old_matrix.block(0,0,old_rows,old_cols)Matrix::Zero(rows, cols) std::vector> Eigen::MapEigen::Mapnew double[n]segmentation fault-mavxmovapsMapUnalignedEigen::Map(ptr, n) Eigen::aligned_allocatorstd::vectorEigen::VectorXd::Map(ptr, n)Unaligned