从GCC 4.6.3移植至5.4.0时basic_string.h编译报错求助

这种从GCC 4.6跳到5.4的编译问题我碰到过好多次，核心原因大多是GCC 5系列对C++标准的严格性大幅提升，再加上默认编译选项和系统库的变化，很多旧代码的“灰色地带”会被揪出来。而且你说错误提示指向的行不对，这在模板相关的错误里特别常见——GCC的错误追踪有时候会停在模板调用点，而不是真正出问题的模板定义处。

下面是几个大概率的原因和对应的解决步骤：

1. 默认C++标准的变更 #

GCC 4.6默认用的是-std=gnu++03（带GNU扩展的C03），而GCC 5.4默认切换到了-std=gnu++11。C11带来了很多行为变化，比如：

• 对隐式转换的限制更严格：比如NULL（本质是0）和nullptr的类型区分，旧代码用NULL赋值给指针类型可能没问题，但在C++11里如果涉及模板推导，会直接触发类型不匹配错误；
• 模板两阶段查找执行更彻底：之前GCC可能忽略了依赖名称的查找问题，现在会严格按照标准报错；
• 新增关键字的冲突：比如constexpr、thread_local这些C++11关键字，如果你的代码里把它们用作变量名，直接就会报错。

解决方法：
先试试给GCC 5.4加上-std=gnu++03编译选项，如果能正常通过，那基本就是标准变化导致的问题。接下来可以逐步切换到-std=gnu++11，结合警告信息（比如-Wall -Wextra）排查具体哪个特性冲突了。

2. 错误提示的“误导性” #

GCC处理模板错误时，经常会把错误指向模板的调用行，而不是模板内部真正出错的地方。比如你看到错误在foo.cpp的第100行，但实际问题是在某个模板函数的定义里，比如第200行的类型转换错误。

解决方法：
把编译错误日志往上翻，找到最开始的error:条目，或者带有required from here的行——这些行才是真正的错误源头。比如模板错误的日志链里，最底层的错误会告诉你“无法将X类型转换为Y类型”或者“找不到匹配的重载函数”。

3. 系统库（libstdc++）的变化 #

Ubuntu 16.04配套的libstdc++是和GCC 5.x绑定的，相比Ubuntu 12.04的版本，很多STL接口有变化：

• 一些旧的非标准扩展被移除；
• 某些STL容器的成员函数签名调整（比如std::list::size()在C++11里变成了O(1)，但旧代码如果依赖之前的O(n)行为可能间接出问题）；
• 头文件的包含关系变化，比如某些之前自动包含的头文件现在需要显式包含了。

解决方法：
如果错误涉及STL类或函数，检查对应的文档，看看GCC 5.x的libstdc有没有废弃或修改相关接口。比如旧代码用std::auto_ptr的话，建议换成std::unique_ptr，因为C11里auto_ptr已经被废弃了。

4. 隐式转换与类型推导的严格检查 #

GCC 5对类型匹配的检查更严，比如：

• 从int到bool的隐式转换如果出现在模板上下文里，可能会触发警告甚至报错；
• void*到其他指针类型的隐式转换，现在需要显式static_cast；
• 模板参数推导时，不再允许模糊的类型匹配。

解决方法：
检查错误提示里的类型不匹配信息，把隐式转换改成显式转换，或者调整模板参数的定义，让推导更明确。

举个实际例子：如果旧代码里有这样的模板：

template <typename T>
void print(T val) {
    int num = val;
    std::cout << num << std::endl;
}

调用print(nullptr)时，GCC 4.6可能会把nullptr隐式转成int（虽然这是不好的写法），但GCC 5会直接报错，错误提示可能指向调用print(nullptr)的行，但真正的问题是模板里把std::nullptr_t赋值给int的操作。

内容的提问来源于stack exchange，提问作者JOH