serafim Asked:2020-01-23 15:48:00 +0000 UTC2020-01-23 15:48:00 +0000 UTC 2020-01-23 15:48:00 +0000 UTC 自定义文字大写 772 它在cppreference上说以下代码会引发错误(例如在文字运算符部分末尾的示例),但是在我的 gcc 中,所有内容都可以在没有任何消息的情况下编译。为什么? double operator"" _Z(long double) { return 0; }; c++ 2 个回答 Voted Best Answer user7860670 2020-01-23T16:37:56Z2020-01-23T16:37:56Z 以下划线和大写字母开头的标识符保留用于实现。但单独使用它们并不一定是错误的。用户定义的文字确实有一个例外,允许在合并写作中使用其他保留的标识符。标准中以这种情况为例: 16.5.8 用户定义文字 [over.literal] 8. double operator""_Bq(long double); // OK:不使用保留标识符 _Bq (5.10) double operator"" _Bq(long double);// 使用保留标识符 _Bq (5.10) 这是一个更具体的例子。VC++ 有使用带有保留标识符的宏的 SAL 注释,例如_In_ #include <sal.h> double operator""_In_(long double) { // гарантировано работает return 0; } double operator"" _In_(long double) { // ошибка в vc++ или clang (c SAL) но работает в gcc return 0; } AnT stands with Russia 2020-01-23T16:21:32Z2020-01-23T16:21:32Z cppreference 上的示例只是想说like 的名称_Z是保留的。也就是说,该示例中的错误与例如声明中的错误相同 int _Z; 但是,编译器不诊断此类违规行为也就不足为奇了。这些名称保留给实现使用,但是当编译器接收到一个已经“组装”的翻译单元作为输入时,已经很难或不可能区分哪些代码是用户定义的,哪些属于实现。因此,编译器很难知道每次使用保留名称是否违规。
以下划线和大写字母开头的标识符保留用于实现。但单独使用它们并不一定是错误的。用户定义的文字确实有一个例外,允许在合并写作中使用其他保留的标识符。标准中以这种情况为例:
这是一个更具体的例子。VC++ 有使用带有保留标识符的宏的 SAL 注释,例如
_In_cppreference 上的示例只是想说like 的名称
_Z是保留的。也就是说,该示例中的错误与例如声明中的错误相同但是,编译器不诊断此类违规行为也就不足为奇了。这些名称保留给实现使用,但是当编译器接收到一个已经“组装”的翻译单元作为输入时,已经很难或不可能区分哪些代码是用户定义的,哪些属于实现。因此,编译器很难知道每次使用保留名称是否违规。