遵循Stroustrup建议，C++构造函数初始化列表用大括号初始化常量有副作用吗？

好问题！虽然Bjarne Stroustrup大力推荐初始化时优先使用大括号，但在构造函数初始化列表里用它给常量成员赋值，确实有几个需要留意的「副作用」——其实大多是大括号初始化的安全特性，只是在某些场景下可能和你的预期不符：

• 窄化转换被强制禁止
  这是大括号初始化最核心的安全特性，但也可能成为「麻烦」。如果你的常量成员是一个窄类型（比如const int），而你传入的是一个宽类型的值（比如double或long），圆括号初始化会默默完成隐式窄化转换，但大括号会直接触发编译错误：

  class Foo {
  public:
      Foo(double val) : a_{val} {} // ❌ 编译错误：禁止窄化转换
      // Foo(double val) : a_(val) {} // ✅ 可以编译，隐式转成int（可能丢失精度）
  private:
      const int a_;
  };
  

  如果你确实需要这种转换，必须显式强转（比如a_{static_cast<int>(val)}），这会增加一点代码量，但也避免了意外的精度丢失。

• 与std::initializer_list构造函数的优先级冲突
  如果你的常量成员是一个支持std::initializer_list的类型（比如std::vector、std::map），或者你的类本身有接受initializer_list的构造函数，大括号初始化会优先匹配这个路径，可能导致意外的行为：

  class Foo {
  public:
      Foo() : vec_{1,2,3} {} // ✅ 正常初始化vector为[1,2,3]
      // 但如果类有这样的构造函数：
      // Foo(std::initializer_list<int>) { /* ... */ }
      // 那么创建Foo对象时 Foo{1,2,3} 会优先调用这个构造函数，而非其他重载
  private:
      const std::vector<int> vec_;
  };
  

  对于基本类型的常量成员，这个问题几乎不会出现，但处理复杂类型时需要留意构造函数的匹配优先级。

• 旧编译器的兼容性问题
  虽然C++11已经普及多年，但一些非常老旧的编译器（比如GCC 4.6之前、MSVC 2012之前）对构造函数初始化列表中的大括号语法支持不完善，可能出现编译错误或奇怪的行为。如果你的代码需要兼容这些旧环境，这会是一个实际的限制。

总的来说，这些「副作用」本质上是大括号初始化的安全设计带来的 trade-off——它避免了很多隐式转换和歧义问题，但需要你在特定场景下调整代码写法。如果不需要兼容旧编译器且能接受严格的类型检查，遵循Stroustrup的建议是非常稳妥的选择。

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