C++中struct结构体不同初始化写法的差异及实现原因咨询

第二种写法的本质问题 #

你给出的第二种写法是存在严重bug的错误写法，完全不可用：
构造函数内部声明的int A = 0;、float B = 0.0f;是和结构体成员同名的局部变量，会直接遮蔽结构体的成员变量，执行构造函数时根本不会给成员A、B赋值，最终创建的对象成员都是未初始化的随机垃圾值。

第一种（构造函数内赋值）和第三种（类内初始化）的核心区别 #

1. 语法支持范围 #

类内成员默认初始化是C11版本才引入的新特性，C03及更早的C++标准完全不支持该语法。

2. 执行逻辑差异 #

对于int、float这类内置类型成员，两种写法的最终运行效果没有差异；如果是自定义类型的成员：

• 第一种写法会先执行成员的默认构造函数，再执行赋值操作，相当于两步操作
• 第三种写法会直接调用对应参数的构造函数完成初始化，仅需一步操作，性能更优，也能兼容没有默认构造函数的自定义成员类型

3. 聚合初始化兼容性 #

C11、C14标准规定，存在类内初始值的结构体不属于聚合类型，无法使用Sabc s{1, 2.0f};这类聚合初始化语法，该限制直到C17才被取消。如果项目基于C11/14开发，用第三种写法会导致原有聚合初始化代码编译失败。

大型项目选择第一种写法的常见原因 #

• 向下兼容要求：很多大型传统项目、嵌入式项目迭代周期长达十余年，需要兼容C03甚至更早的编译标准，根本无法使用C11的类内初始化特性。
• 编译器稳定性考虑：部分老旧的业务专用编译器、交叉编译器对C11新特性的支持存在缺陷，构造函数内赋值是所有C标准都原生支持的通用写法，兼容风险最低。
• 代码规范一致性：老项目长期形成的编码规范要求所有初始化逻辑收敛到构造函数内部，避免部分初始化逻辑散落在类内声明处，降低后续维护的理解成本。
• 扩展灵活性更高：构造函数内可以方便的添加参数校验、调试日志、分支判断等附加逻辑，后续调整初始化规则时比类内初始化的灵活度更高。
• 兼容现有聚合初始化逻辑：如果项目大量使用聚合初始化语法，在C++17之前的标准下，第一种写法不会破坏结构体的聚合属性，不会影响现有业务代码的正常编译。

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