现代C++嵌入式教程：C++98基础特性：从C到C++的演进（1）

C++98基础特性：从C到C++的演进

完整的仓库地址在Tutorial_AwesomeModernCPP中，您也可以光顾一下，喜欢的话给一个Star激励一下作者

在上一章中，我们系统回顾了C语言的核心语法，这些知识是理解C++的基础。C++最初被设计为"C with Classes"，即在保持C语言高效性的同时，引入面向对象编程的特性。本章将专注于C++98标准中引入的基础特性，这些特性使得C++成为一门更加强大和表达力更强的语言，同时在嵌入式系统中仍然保持高效。

不过，其实C++98开始就有模板了，但是笔者没有介绍，是因为模板本身就很复杂，我们必须单独开几章讲（以C++ Template为代表的著作甚至专门介绍了模板编程，笔者看过，小六七百页呢）

1. 命名空间 (Namespace)

命名空间是C++引入的一个重要特性，用于组织代码并避免命名冲突。在大型嵌入式项目中，特别是使用多个第三方库时，命名空间可以有效地防止标识符冲突。这个东西不会再任何层次上干扰性能。因为他最终只是退化成带有命名空间修饰的符号名称。所以这个好用的特性，能用就用。

1.1 命名空间的定义与使用

cpp 复制代码

// 定义命名空间
namespace sensor {
    const int MAX_READINGS = 100;
    
    struct Reading {
        float temperature;
        float humidity;
    };
    
    void init();
    Reading get_reading();
}

// 实现命名空间中的函数
namespace sensor {
    void init() {
        // 初始化传感器
    }
    
    Reading get_reading() {
        Reading r;
        // 读取数据
        return r;
    }
}

// 使用命名空间
int main() {
    // 完全限定名
    sensor::init();
    sensor::Reading data = sensor::get_reading();
    
    // 使用using声明
    using sensor::Reading;
    Reading data2 = sensor::get_reading();
    
    // 使用using指令（不推荐在头文件中使用, 有个知乎回答专门聊using namespace的，感兴趣搜下）
    using namespace sensor;
    init();
    Reading data3 = get_reading();
    
    return 0;
}

1.2 嵌套命名空间

命名空间可以嵌套，这在组织复杂的代码库时非常有用，举个例子，以基础库下，我们有高性能高精度乘法函数，在C里，我们写：BasicComponent_HighResolution_multiply，现在不用这么又臭又长的，直接写basic::high_resolution::multiply，特别结合上面提到的using namespace，咱们如果这个文件下所有的运算都是这个命名空间下的运算函数，那就直接using namespace即可。

或者一个嵌入式的朋友看得懂的代码：

cpp 复制代码

namespace hardware {
    namespace gpio {
        enum PinMode {
            INPUT,
            OUTPUT,
            ALTERNATE
        };
        
        void set_mode(int pin, PinMode mode);
    }
    
    namespace uart {
        void init(int baudrate);
        void send(const char* data);
    }
}

// 使用
hardware::gpio::set_mode(5, hardware::gpio::OUTPUT);
hardware::uart::init(115200);

// 或者使用别名简化
namespace hw = hardware;
hw::gpio::set_mode(5, hw::gpio::OUTPUT);

1.3 匿名命名空间

匿名命名空间提供文件级别的作用域，替代C语言中的static关键字，虽然等价，但是现在你终于不用给每一个想藏起来变量和函数都搞一个static了。

cpp 复制代码

// 在C++中推荐使用匿名命名空间而非static
namespace {
    // 这些变量和函数只在本文件可见
    const int BUFFER_SIZE = 256;
    
    void internal_helper() {
        // 内部辅助函数
    }
}

void public_function() {
    internal_helper();  // 可以直接调用
}

2. 引用 (Reference)

引用是C++引入的一个重要特性，它为变量提供了一个别名。引用在很多方面比指针更安全、更方便，特别是在函数参数传递中。这个东西，仁者见仁智者见智，在C++里，您可以放心的代替很多希望修改本变量的指针为引用。下面是使用的例子，不过，很少人这样写引用，这里只是说明：

cpp 复制代码

int value = 42;
int& ref = value;  // ref是value的引用（别名）

ref = 100;         // 修改ref就是修改value
// 此时value也变成了100

// 引用必须在声明时初始化
// int& bad_ref;   // 错误：引用必须初始化

// 引用一旦绑定就不能重新绑定到其他变量
int other = 200;
ref = other;       // 这不是重新绑定，而是将other的值赋给value

2.2 引用作为函数参数

更多的情况下，我们使用引用参数是为了避免了拷贝开销（也就是老生常谈的形参实参问题），在嵌入式系统中特别有用：

cpp 复制代码

// 传值：拷贝整个结构体（低效）
void process_by_value(SensorData data) {
    // data是副本
}

// 传指针：需要检查空指针，语法稍显笨拙
void process_by_pointer(SensorData* data) {
    if (data != nullptr) {
        data->temperature += 10;  // 需要使用->
    }
}

// 传引用：高效且语法简洁
void process_by_reference(SensorData& data) {
    data.temperature += 10;  // 直接使用.操作符
    // 不需要空指针检查，一般下，引用总是有效的，除非你的对象失效了！
}

// const引用：既高效又防止修改
void read_only_access(const SensorData& data) { // 在C++98中很常见的用法
    float temp = data.temperature;  // 可以读取
    // data.temperature = 0;  // 错误：不能修改const引用
}

2.3 引用作为返回值

函数可以返回引用，但需要特别小心不要返回局部变量的引用：

cpp 复制代码

class Buffer {
private:
    uint8_t data[256];
    size_t size;
    
public:
    // 返回引用允许连续调用
    Buffer& append(uint8_t byte) {
        if (size < 256) {
            data[size++] = byte;
        }
        return *this;  // 返回当前对象的引用
    }
    
    // 允许通过引用访问元素
    uint8_t& operator[](size_t index) {
        return data[index];
    }
    
    // const版本
    const uint8_t& operator[](size_t index) const {
        return data[index];
    }
};

// 使用
Buffer buf;
buf.append(0x01).append(0x02).append(0x03);  // 链式调用
buf[0] = 0xFF;  // 通过引用修改元素

**警告：不要返回局部变量的引用！**本质上，他只是告诉编译器，不要单独的拷贝对象出来操作临时的拷贝对象，现在如果你返回了栈上对象的引用，他们在return的时候就被销毁了，所以返回栈上对象的引用是很危险的，更是一种低级错误，永远不要做这种事情！

cpp 复制代码

// 危险！不要这样做！
int& dangerous_function() {
    int local = 42;
    return local;  // 返回局部变量的引用（未定义行为）
}

// 正确的做法
int& safe_function(int& input) {
    return input;  // 返回参数的引用是安全的
}

3. 函数重载 (Function Overloading)

函数重载允许多个函数使用相同的名称，只要它们的参数列表不同。这使得API设计更加直观和灵活。但这个东西从不同的层次上会带来麻烦------比如说，导出重载函数的符号。

3.1 基本函数重载

基本的函数重载就这样用：

cpp 复制代码

// 不同参数类型的重载
void print(int value) {
    printf("Integer: %d\n", value);
}

void print(float value) {
    printf("Float: %f\n", value);
}

void print(const char* str) {
    printf("String: %s\n", str);
}

// 不同参数数量的重载
void init_uart(int baudrate) {
    // 使用默认配置
}

void init_uart(int baudrate, int databits, int stopbits) {
    // 使用自定义配置
}

// 使用
print(42);           // 调用print(int)
print(3.14f);        // 调用print(float)
print("Hello");      // 调用print(const char*)

OK，这次我完全按"博客正文文段"来重写 ，不再拆成教学式小块，也不做列表堆砌，而是一口气讲清楚编译器在想什么，你可以直接整体贴进文章里用。

3.2 重载解析规则

在 C++ 中，看似简单的一次函数调用，背后其实隐藏着一套非常严格、近乎"冷酷"的决策流程。每当你调用一个存在多个重载版本的函数时，编译器都会先收集所有名字匹配、参数数量一致的候选函数，然后对它们逐一评估，试图回答一个问题：**哪一个是"最合适"的？**这个过程被称为重载解析（Overload Resolution）。需要强调的是，编译器并不会理解你的业务语义，它只会机械地按照语言规则打分，最终选出匹配度最高的那个版本。

在不涉及模板、可变参数等复杂因素的前提下，编译器的判断标准可以理解为一条由强到弱的"匹配优先级链"。首先是精确匹配，也就是实参与形参类型完全一致；如果不存在精确匹配，才会考虑类型提升，比如 char 提升为 int；再往后才是标准类型转换，例如 int 转换为 double；最后才轮到用户自定义的类型转换。这个顺序非常重要，因为它意味着：只要某一层级已经能找到可行的匹配，后面的规则就完全不会被考虑，哪怕它们在"人类直觉"中看起来更合理。

举一个最常见的例子，如果我们同时定义了 process(int) 和 process(double) 两个函数，不用太麻烦，您直接写这两行就行：

cpp 复制代码

void process(int x) { }
void process(double x) { }

那么调用 process(5) 时，编译器几乎不需要思考：字面量 5 本身就是 int，这属于精确匹配，而 process(double) 需要一次从 int 到 double 的转换。在重载解析的规则下，精确匹配对任何形式的转换都有压倒性优势，因此最终调用的一定是 process(int)。同样地，调用 process(5.0) 时，5.0 是 double，这一次精确匹配发生在 process(double) 上，另一个版本反而需要进行带有精度风险的转换，自然会被淘汰。

稍微容易让人困惑的是 process(5.0f) 这种情况。5.0f 的类型是 float，而我们并没有 process(float) 的重载。此时编译器会比较两条可能的路径：float 转换为 double，以及 float 转换为 int。前者是浮点类型之间的标准提升，被认为更加自然、安全；后者则涉及截断语义，因此优先级更低。结果是，哪怕你没有显式写出 double，最终仍然会调用 process(double)。这也体现了一个事实：重载解析并不是"最少字符匹配"，而是"最合理的类型路径匹配"。

真正让人头疼的情况，往往出现在规则无法分出高下的时候。比如同时存在 func(int, double) 和 func(double, int) 两个重载，当你调用 func(5, 5) 时，从人的角度看似乎"随便选一个也行"，但在编译器眼里，这两个候选函数的匹配成本是完全一样的：对于第一个版本，一个参数是精确匹配、另一个需要标准转换；对于第二个版本，情况正好对称。两边的"代价"一模一样，没有任何一个能在规则层面胜出。此时，编译器不会尝试揣测你的意图，而是直接判定调用存在歧义，并以错误终止编译。

这背后反映的是 C++ 一个非常重要、也非常"工程化"的设计理念：只要存在同样可行、但无法比较优劣的选择，编译器宁可拒绝编译，也不会替程序员做决定 。这正是 C++ 强类型系统的底色------明确性永远高于便利性（这里，即便是这样方便的语法也不能触犯的底线）。从实践角度来说，这也意味着我们在设计接口时，应当尽量避免仅靠参数顺序或微妙的类型差异来区分重载，尤其是在涉及内置类型或隐式转换时。一旦出现歧义，最可靠的做法永远是把类型写清楚，而不是寄希望于编译器"刚好懂你"。

如果要用一句话来总结这一节，那就是：重载解析不是智能推断，而是一套冷静、刻板的规则系统；当你觉得"它应该能工作"的时候，往往正是它最容易报错的时候。