6

なぜこのようなコードを書くことができないのか疑問に思っています:

constexpr double radius = 27_km.to_miles(); // _km returns Distance instance 
                                            // which has to_miles()

GCC 4.8.1 と Clang 3.4 の両方が、括弧で囲まoperator"" _km.to_milesないとリテラル演算子が見つからないと文句を言います。27_km

constexpr double radius = (27_km).to_miles(); // fine

標準のセクション 2.14.8 を読んだところ、UDL サフィックスにピリオドを含めることはできないのに、なぜコンパイラはこのようにコードを解析するのでしょうか? それらは正しいですか、それともバグですか?

編集: 完全な例 (さまざまな UDL とメソッド名) をここで見ることができます: http://ideone.com/rvB1pk

4

2 に答える 2

3

UDL の接尾辞は通常の識別子 (先頭にアンダースコアが付いている) であるはずなので、バグのように見えます。

于 2013-10-16T04:04:49.813 に答える
2

これはレクサーの問題である可能性があります。ユーザー定義のリテラルは、単一のチャンクとしてトークン化されます。数字とサフィックスが 1 つの完全なトークンです。数値リテラルの場合、丸呑みできる文字には小数点の「.」が含まれます。Lookup pp-number: セクション 2.10 - 標準の最新ドラフトの lex.ppnumber。プリプロセッサ (レクサー) がトークンをスキャンする方法について説明します。

30_au.to_light_years()

digit
digit
identifier-nondigit
.
identifier-nondigit x 14
( breaks the spell

したがって、プリプロセッサ30_au.to_light_yearsは大きな異常な (浮動小数点) 数として認識します。その後、数値の解析段階で、「-」以降digit, digit, identifier-nondigit... の残りが接尾辞識別子として渡されます。

数値リテラルは、プリプロセッサがトークン化した後に解釈されることに注意してください。

これは実際には欠陥ではないと思います。

于 2013-10-17T05:02:04.373 に答える