Bla*_*ger 1 c++ grammar casting language-lawyer braced-init-list
考虑:
\n(long long){1};\nRun Code Online (Sandbox Code Playgroud)\nIt\xe2\x80\x99s 不是C 风格的转换表达式每个 [expr.cast]/1 的
\n\n\n表达式 (T) 强制转换表达式的结果为 T 类型。如果 T 是左值引用类型或对函数类型的右值引用,则结果是左值;如果 T 是对对象类型的右值引用,则结果是 xvalue;否则结果是纯右值。
\n
\n\n强制转换表达式:
\n\n
\n- 一元表达式
\n- ( type-id ) 强制转换表达式
\n
{1}不应该是强制转换表达式。
它也不是每个 [expr.type.conv]/1 的函数式转换表达式:
\n\n\n简单类型说明符或类型名说明符后跟带括号的可选表达式列表或大括号初始化列表(初始化程序),在给定初始化程序的情况下构造指定类型的值。如果该类型是推导类类型的占位符,则它将替换为本子条款其余部分的类模板推导重载决策所选择的函数的返回类型。否则,如果类型包含占位符类型,则将其替换为由占位符类型推导 ([dcl.type.auto.deduct]) 确定的类型。
\n
\n\n简单类型说明符:
\n\n
\n- 嵌套名称说明符 opt 类型名称
\n- 嵌套名称说明符模板简单模板 ID
\n- decl类型说明符
\n- 占位符类型说明符
\n- 嵌套名称说明符 opt 模板名称
\n- 字符
\n- char8_\xc2\xadt
\n- char16_\xc2\xadt
\n- char32_\xc2\xadt
\n- wchar_\xc2\xadt
\n- 布尔值
\n- 短的
\n- 整数
\n- 长的
\n- 签
\n- 未签名
\n- 漂浮
\n- 双倍的
\n- 空白
\n
(long long)不应该是simple-type-specifier。
这看起来不合法,但应该是,为什么?
\n它不是 ISO 标准 C++ 中的有效语法。
在 C 中,它是复合文字的语法。默认情况下,编译器通常也支持 C++ 模式下的扩展。当启用严格(呃)标准一致性时,他们应该拒绝它或至少提供警告(例如,带有-pedantic, -pedantic-errors)
顺便说一句,是否有多个单词并不重要。(long){1}有同样的问题。(/*..*/){/*..*/}从您给出的标准引号中可以看出,不能是表达式的语法。
此外,在 C 中,这样的复合文字是类似字符串文字的左值。这在 C++ 中会令人困惑,其中类似的强制转换表达式(即T{1}with using T=long long;)会生成纯右值。生成的对象的生命周期也非常不同。因此,在 C++ 中支持它们要么与 C 中具有不同的含义,要么意味着(T){e}和之间存在令人困惑的差异T{e}。
这是 2020-2022 年在 C++ 中引入复合文字的封闭提案。正如您从投票结果中看到的那样,对于是否添加它们或者它们应该具有什么行为没有达成共识。
| 归档时间: |
|
| 查看次数: |
108 次 |
| 最近记录: |