例如,我不能这样写:
class A
{
vector<int> v(12, 1);
};
我只能这样写:
class A
{
vector<int> v1{ 12, 1 };
vector<int> v2 = vector<int>(12, 1);
};
对C ++ 11语言设计差异的考虑是什么?
答案 0 :(得分:28)
在非静态数据成员初始化程序的相关proposal中明确提到了此选择背后的基本原理:
Kona就标识符范围提出了一个问题:
在2007年9月Kona会议的核心工作组讨论期间,出现了关于初始化程序中标识符范围的问题。我们是否希望允许类范围具有正向查找的可能性;或者我们是否要求在解析它们时明确定义初始化器?
想要什么:
类范围查找的动机是我们希望能够将任何内容放入非静态数据成员的初始化程序中,我们可以将其放入mem-initializer而不会显着改变语义(模数直接初始化与复制初始化):
int x();
struct S {
int i;
S() : i(x()) {} // currently well-formed, uses S::x()
// ...
static int x();
};
struct T {
int i = x(); // should use T::x(), ::x() would be a surprise
// ...
static int x();
};
问题1:
不幸的是,这使得“(表达式列表)”的初始化程序在解析声明时不明确:
struct S {
int i(x); // data member with initializer
// ...
static int x;
};
struct T {
int i(x); // member function declaration
// ...
typedef int x;
};
一种可能的解决方案是依赖现有规则,如果声明可以是对象或函数,那么它就是一个函数:
struct S {
int i(j); // ill-formed...parsed as a member function,
// type j looked up but not found
// ...
static int j;
};
类似的解决方案是应用另一个现有规则,目前仅在模板中使用,如果T可以是类型或其他东西,那么它就是其他东西;如果我们真的是一个类型,我们可以使用“typename”:
struct S {
int i(x); // unabmiguously a data member
int j(typename y); // unabmiguously a member function
};
这两种解决方案都引入了很多可能被许多用户误解的细微问题(关于comp.lang.c ++上关于为什么“int i();”的许多问题都证明了这一点。“在块范围内没有声明默认值 - 初始化int)。
本文提出的解决方案是仅允许“= initializer-clause”和“{initializer-list}”表单的初始值设定项。这解决了大多数案例中的歧义问题,例如:
HashingFunction hash_algorithm{"MD5"};
这里,我们不能使用=形式,因为HasningFunction的构造函数是显式的。 在特别棘手的情况下,可能必须提到两次类型。考虑:
vector<int> x = 3; // error: the constructor taking an int is explicit
vector<int> x(3); // three elements default-initialized
vector<int> x{3}; // one element with the value 3
在这种情况下,我们必须使用适当的符号在两种备选方案之间进行选择:
vector<int> x = vector<int>(3); // rather than vector<int> x(3);
vector<int> x{3}; // one element with the value 3
问题2:
另一个问题是,因为我们建议不要更改初始化静态数据成员的规则,所以添加static关键字可能会使格式良好的初始化程序形成错误:
struct S {
const int i = f(); // well-formed with forward lookup
static const int j = f(); // always ill-formed for statics
// ...
constexpr static int f() { return 0; }
};
问题3:
第三个问题是类范围查找可能会将编译时错误转换为运行时错误:
struct S {
int i = j; // ill-formed without forward lookup, undefined behavior with
int j = 3;
};
(除非被编译器捕获,否则我可能会使用未定义的j值进行初始化。)
提案:
CWG在Kona进行了6比3的民意调查,支持分类范围查询;这就是本文提出的建议,非静态数据成员的初始化程序仅限于“= initializer-clause”和“{initializer-list}”形式。
我们相信:
问题1:由于我们不提出()表示法,因此不会发生此问题。 =和{}初始值表示法不会遇到此问题。
问题2:添加静态关键字会产生许多差异,这是最不重要的。
问题3:这不是一个新问题,但与构造函数初始化程序已存在的初始化顺序问题相同。
答案 1 :(得分:20)
一个可能的原因是允许括号会立即将我们带回most vexing parse。请考虑以下两种类型:
struct foo {};
struct bar
{
bar(foo const&) {}
};
现在,您有一个要初始化的bar
类型的数据成员,因此您将其定义为
struct A
{
bar B(foo());
};
但是你上面所做的是声明一个名为B
的函数,该函数按值返回bar
个对象,并获取一个具有签名foo()
的函数的参数(返回a foo
并且不接受任何参数。)
根据处理此问题的StackOverflow问题的数量和频率来判断,这是大多数C ++程序员发现令人惊讶和不直观的事情。添加新的 brace-or-equal-initializer 语法是一个避免这种模糊性的机会,并从一个干净的平板开始,这可能是C ++委员会选择这样做的原因。
bar B{foo{}};
bar B = foo();
上面的两行都按预期声明了一个名为B
的{{1}}类型的对象。
除了上面的猜测之外,我想指出你在上面的例子中做了两件截然不同的事情。
bar
第一行将vector<int> v1{ 12, 1 };
vector<int> v2 = vector<int>(12, 1);
初始化为包含两个元素v1
和12
的向量。第二个创建一个包含1
元素的向量v2
,每个元素都初始化为12
。
注意这个规则 - 如果类型定义了一个带1
的构造函数,那么当该类型的初始化程序是支撑时,该构造函数始终始终 -init列表。仅当采用initializer_list<T>
的人不可行时,才会考虑其他构造函数。