NIOS II移植Arduino框架：如何兼容不同C库下的String::toDouble()？

针对你的需求，我们可以利用链接器的符号解析特性和无用段回收来实现兼容GCC 4.7.3和5.3.0的方案，不需要编译时宏定义，具体步骤如下：

1. 保留String::toDouble()的声明 #

在String.h头文件中保持原有的函数声明不变，确保用户代码可以正常引用：

class String {
    // ... 其他成员 ...
    double toDouble() const;
};

2. 实现依赖atof()的toDouble()函数 #

创建一个单独的源文件（比如StringDouble.cpp），实现String::toDouble()，直接依赖标准库的atof()：

#include "String.h"

double String::toDouble() const {
    // 直接调用atof()，依赖标准C库提供该函数
    return atof(this->c_str());
}

3. 确保构建系统启用无用段回收 #

确认你的NIOS II构建系统启用了GCC的-ffunction-sections和链接器的--gc-sections选项（Arduino框架通常默认启用这些选项）。这些选项会让链接器自动丢弃未被引用的函数代码段，这是方案生效的关键。

方案如何满足你的需求 #

• 场景1：使用小型C库且未调用String::toDouble()
  由于toDouble()没有被引用，链接器会丢弃StringDouble.cpp中的函数代码段，不会尝试解析atof()符号，因此编译链接可以正常完成。

• 场景2：使用小型C库且调用了String::toDouble()
  链接器需要拉入toDouble()的实现代码，而小型C库没有提供atof()，因此会触发链接错误：undefined reference to 'atof'。你可以在框架文档中补充说明：如果出现该错误，意味着当前使用了小型C库，无法使用String::toDouble()函数。

• 场景3：使用标准C库
  无论用户是否调用toDouble()，标准C库都提供atof()，因此链接器可以正常解析符号，编译链接全程无错误。

优化：让报错信息更友好（可选） #

如果你希望错误提示更直接，可以修改实现，让小型库下的调用触发更明确的错误：

1. 创建两个实现文件：

   • StringDouble_std.cpp（标准库版本）：和之前的实现一致，调用atof()；
   • StringDouble_small.cpp（小型库版本）：

     #include "String.h"
     // 声明一个不存在的函数，名字包含错误提示
     extern void __error_String_toDouble_unavailable_with_small_C_library();
     
     double String::toDouble() const {
         __error_String_toDouble_unavailable_with_small_C_library();
         return 0.0; // 避免编译警告
     }
     

2. 修改构建系统的链接逻辑：

   • 当使用标准C库（链接选项-lc）时，链接StringDouble_std.o；
   • 当使用小型C库（链接选项-lc_s）时，链接StringDouble_small.o。

这样，当用户在小型库下调用toDouble()时，链接器会报错：undefined reference to '__error_String_toDouble_unavailable_with_small_C_library'，错误信息更清晰，用户可以直接明白问题所在。

这个方案兼容GCC 4.7.3和5.3.0，因为所有用到的特性（函数段、垃圾回收、静态链接符号解析）都是这两个版本支持的标准功能。

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