英文:
Is (multi-word type name){expression-list} legal?
问题
以下是翻译好的部分：
"(long long){1}" 不应该是一个C风格的类型转换表达式，根据[expr.cast]/1：
表达式(T) cast-expression 的结果类型为T。如果T是左值引用类型或函数类型的右值引用，则结果是左值，如果T是对象类型的右值引用，则结果是x值；否则，结果是纯右值。
"cast-expression" 定义如下：
- 一元表达式
- ( type-id ) cast-expression
"{1}" 不应该是一个cast-expression。
它也不是一个函数式类型转换表达式，根据[expr.type.conv]/1：
简单类型指定符或类型名指定符后跟一个带括号的可选表达式列表，或者带大括号的初始化列表（初始化项），根据初始化项构造指定类型的值。如果类型是一个用于推断类类型的占位符，它在本子句的其余部分被选择用于类模板推断的函数的返回类型替换。否则，如果类型包含占位符类型，它将被占位符类型推导确定的类型替换。
"simple-type-specifier" 定义如下：
- 可选的嵌套名称指定符类型名
- 可选的嵌套名称指定符模板简单模板ID
- decltype指定符
- 占位符类型指定符
- 可选的嵌套名称指定符模板名
- char
- char8_t
- char16_t
- char32_t
- wchar_t
- bool
- short
- int
- long
- signed
- unsigned
- float
- double
- void
"(long long)" 不应该是一个simple-type-specifier。
这似乎不合法，但它应该是合法的，为什么呢？
英文:
Consider:
(long long){1};
It’s not a C-style cast expression per [expr.cast]/1:
>The result of the expression (T) cast-expression is of type T. The result is an lvalue if T is an lvalue reference type or an rvalue reference to function type and an xvalue if T is an rvalue reference to object type; otherwise the result is a prvalue.
> cast-expression:
>* unary-expression
>* ( type-id ) cast-expression
{1} shouldn't be a cast-expression.
It's also not a functional-style cast expression per [expr.type.conv]/1:
>A simple-type-specifier or typename-specifier followed by a parenthesized optional expression-list or by a braced-init-list (the initializer) constructs a value of the specified type given the initializer. If the type is a placeholder for a deduced class type, it is replaced by the return type of the function selected by overload resolution for class template deduction for the remainder of this subclause. Otherwise, if the type contains a placeholder type, it is replaced by the type determined by placeholder type deduction ([dcl.type.auto.deduct]).
> simple-type-specifier:
> * nested-name-specifier opt type-name
> * nested-name-specifier template simple-template-id
> * decltype-specifier
> * placeholder-type-specifier
> * nested-name-specifier opt template-name
> * char
> * char8_t
> * char16_t
> * char32_t
> * wchar_t
> * bool
> * short
> * int
> * long
> * signed
> * unsigned
> * float
> * double
> * void
(long long) shouldn't be a simple-type-specifier.
It doesn't seem legal, but it should be, why?
答案1
得分: 4
这不是ISO标准C++中的有效语法。
在C语言中，这是一个复合字面值的语法。编译器通常默认支持在C++模式下作为扩展。当启用严格的标准遵从性时，它们应该拒绝或至少提供警告（例如使用-pedantic，-pedantic-errors）。
顺便说一下，是否有多个单词并不重要。(long){1}也存在相同的问题。根据您提供的标准引用，(/*..*/){/*..*/}不可能是表达式的语法。
此外，在C中，这样的复合字面值是一个左值，就像字符串字面值一样。这在C++中会令人困惑，因为类似的强制转换表达式，即T{1}，在使用using T=long long;的情况下会产生一个右值。生成对象的生命周期也非常不同。因此，在C++中支持它们要么具有与C中不同的含义，要么意味着在(T){e}和T{e}之间存在令人困惑的差异。
这里是一个自2020年至2022年间提出的关闭提案，旨在在C++中引入复合字面值。从投票结果中可以看出，关于是否要添加它们以及它们应该具有什么行为，没有达成一致意见。
英文:
It is not valid syntax in ISO standard C++.
In C it is the syntax for a compound literal. Compilers by default often support that also in C++ mode as an extension. When enabling strict(er) standard conformance they should reject it or at least provide a warning (e.g. with -pedantic, -pedantic-errors)
Whether there are multiple words doesn't matter by the way. (long){1} has the same problem. (/*..*/){/*..*/} can't be syntax for an expression as can be seen from the standard quotes you gave.
Also, in C such a compound literal is an lvalue like string literals. That would be confusing in C++, where an analogues cast expression, i.e. T{1} with using T=long long;, produces a prvalue. The lifetime of the resulting object is also very different. Therefore supporting them in C++ would either have a different meaning as in C or mean a confusing difference between (T){e}and T{e}.
Here is a closed proposal from 2020-2022 to introduce compound literals in C++. As you can see from the voting results there wasn't a consensus whether to add them at all or what behavior they should have.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论