我有一段非常简单的代码来处理矩阵。这是一个简短的摘录：
typedef boost::multiprecision::cpp_dec_float_100 SuperFloat;
typedef boost::numeric::ublas::matrix<SuperFloat> Matrix;
int function(Matrix& matrix){
boost::numeric::ublas::permutation_matrix<std::size_t> pm(matrix.size1());
int res = lu_factorize(matrix,pm); // this is a problem
return res;
}
代码完美地编译并在我的笔记本上运行，使用g ++ 5.2.0和boost 1.58。 但是，当我尝试在我的桌面计算机上编译相同的代码时，使用gcc 4.9.2和boost 1.53，我收到一条可怕的错误消息（数英里的模板参数），最终会出现这样的结果：
cannot convert ‘boost::numeric::ublas::norm_inf
# gazillions of template arguments
to type ‘const bool&’
std::max<S> (std::max<S> (norm_inf (e1), norm_inf (e2)), min_norm);
stl_algobase.h:261:5: note: template<class _Tp, class _Compare> const _Tp& std::max(const _Tp&, const _Tp&, _Compare)
max(const _Tp& __a, const _Tp& __b, _Compare __comp)
我现在有点困惑。看起来参数的模板解析失败了，这导致max的两个参数属于不同的类型。不幸的是，我无法明确地对它们进行类型转换，因为导致问题的实际调用被隐藏在boost uBLAS中。
由于我能够在笔记本上使用不同的gcc和boost版本编译相同的代码，因此必须存在某种版本问题。从gcc4.9到5.2是否有一些影响模板分辨率的特殊变化，或者是否存在导致此问题的uBLAS问题？
克服这些问题的建议方法是什么？虽然显而易见的解决方案是更新gcc并提升我的工作计算机，但编写依赖于某些版本的gcc或boost来编译代码的代码当然不是很明智。
答案 0 :(得分：1)
从gcc4.9到5.2是否有一些影响模板分辨率的特殊变化，或者是否存在导致此问题的uBLAS问题？
显然，你自己已经分析过了！
克服这些问题的建议方法是什么？
是的，升级升级版。使用该版本的boost支持的编译器版本（Boost非常自由地支持“旧版”编译器）。
编写依赖某些版本的gcc或boost来编译它的代码当然不是很明智。
确实，事实并非如此。所以你写一个合理的最新版本，支持一段时间。
事情是事情不会“随机”破坏。这不像从1.53升级到1.58神奇地修复了你的问题，并打破了其他许多事情。版本正在逐步改进。
因此，如果升级破坏了某些内容，那么就会提交错误报告，因为它是一个回归.¹
在实践中，由于现有测试，这种情况不会经常发生。对于在先前版本中主动修复的任何错误，这是 双重真实 ，因为许多开发人员在修复之前将测试用例创建为复制程序，并且测试保持在< em>完全是为了防止退步。
¹如果库故意进行重大更改，则始终需要在发行说明中进行说明。大多数情况下，旧的行为仍可用于过渡期，可以在不同的命名空间中，也可以在特定的预处理器定义中使用。