C++中构造函数参数与类成员同名的编译器区分及写法分析

不少代码示例中会出现类构造函数的形参与私有成员完全重名的写法，典型实现如下：

class Box
{
public:
    Box(unsigned length, unsigned width, unsigned height)
        : length(length), width(width), height(height)
    {
        std::clog << length << std::endl;
        std::clog << width  << std::endl;
        std::clog << height << std::endl;
    }
private:
    unsigned length, width, height;
};

针对这类写法大家最常问的三个问题，逐一解答如下：

1. 编译器如何区分同名的函数参数与类成员名称？ #

编译器的区分逻辑完全遵循C++标准定义的作用域查找规则，分两个场景明确判定，不存在识别歧义：

• 成员初始化列表场景：语法规则直接限定，冒号后紧跟的标识符必须是当前类的可访问非静态成员，所以length(length)的结构里，第一个length固定绑定类成员；括号内的表达式部分走常规名字查找，优先匹配离当前上下文最近的形参，自然实现“把形参值赋值给对应成员”的初始化效果。
• 构造函数体内部场景：名字查找遵循“局部作用域优先遮蔽外层作用域”的通用规则，函数体内出现的裸标识符length，会优先匹配构造函数的形参，而非类成员。很多新手都踩过这个坑：以为初始化列表已经完成了成员赋值，函数体里打印length读取的是成员值，实际上因为同名遮蔽，打印的还是传入的形参值——哪怕成员已经被初始化完成，只要不通过this->length这类显式限定，就访问不到类成员本身。

2. 这种写法是否属于可移植代码？ #

这种写法属于完全合法的标准语法，具备全场景的可移植性：

• 从C98到最新的C23标准，对初始化列表的绑定规则、函数体内的作用域查找优先级都有统一的明确规定，不存在规范模糊的灰色地带。
• 所有符合标准的C++编译器（GCC、Clang、MSVC等）对这类同名场景的行为完全一致，不会出现A编译器正确初始化成员、B编译器错把形参初始化自身的兼容问题。
• 需要明确的是，函数体里写length = length导致形参给自己赋值、完全不修改类成员的行为，是标准统一规定的确定结果，不属于编译器差异带来的移植问题，只是容易引发逻辑bug的易错点而已。

3. 这种写法是否属于不良编程实践？ #

不存在绝对的对错判定，是否属于坏实践完全取决于团队的统一规范和具体使用场景：

• 这种写法没有任何语法层面的错误，当团队约定类成员不使用任何特殊前缀/后缀（比如不加m_前缀、下划线后缀）时，用同名形参配合初始化列表是非常高效的写法，既减少重复拼写的工作量，也能避免“形参名和成员名不一致导致错配”的低级问题。
• 这种写法的风险只出现在构造函数体存在大量业务逻辑的场景：形参会直接遮蔽同名类成员，很容易出现本来想修改类成员、结果误操作局部参数的bug。如果遇到这种场景，要么用this->显式标记要访问的类成员，要么给类成员加统一的命名前缀从根源避免遮蔽。
• 很多人认为这种写法可读性差，本质是对“局部作用域优先遮蔽类成员”的规则不熟悉，只要团队成员对该规则有统一认知，这种写法完全在可接受范围内，不属于必须禁止的不良实践。

内容的提问来源于stack exchange，提问作者L.S. Roth