1

C++0xのユーザー定義リテラル サフィックスは、次の識別子にする必要があります。

  • (アンダースコア)で始まる_(17.6.4.3.5)
  • 大文字 で始めてはいけません(17.6.4.3.2)_

    [...] がアンダースコアで始まり、その後に大文字が続く各名前は、実装で使用するために予約されています。

_ そのようなサフィックスの後に数字が続かない理由はありますか? または？_4__3musketeers

Musketeer dartagnan = "d'Artagnan"_3musketeers;
int num = 123123_4; // to be interpreted in base4 system?
string s = "gdDadndJdOhsl2"_64; // base64decoder
4

4 に答える 4

1

このテーマに関するいくつかの論文があることは知っていました: Digital Separatorsは、数値リテラルの数字区切り文字として _ を使用する提案について説明しています。

ユーザー定義リテラルのあいまいさと不安リテラル接尾辞の命名と名前空間の予約に関するアイデアの進化と、将来の桁区切り記号に対するユーザー定義リテラルの競合を解消するための取り組みについて説明します。

_ 桁区切り記号にはあまり適していません。

しかし、私には考えがありました: 桁区切り記号のバックスラッシュまたはバッククォートはどうですか? _ ほど良くはありませんが、バックスラッシュが数字のストリーム内にある限り、衝突はないと思います。バックティックには、現在私が知っているレキシカルな用途はありません。

i = 123\456\789;
j = 0xface\beef;

また

i = 123`456`789;
j = 0xface`beef;

これにより、_123 がリテラル サフィックスとして残ります。

于 2011-07-01T06:30:11.893 に答える
1

アンダースコアの後に数字が続くのは、有効なユーザー定義のリテラル サフィックスです。関数のシグネチャは次のようになります: operator"" _4(); そのため、プレースホルダーに食べられませんでした。リテラルは、単一のプリプロセッサ トークンになります: 123123_4; したがって、_4 はプレースホルダーまたはプリプロセッサー シンボルによって破壊されません。

私の 17.6.4.3.5 の読みは、先頭のアンダースコアを含まないサフィックスは、実装または将来のライブラリの追加と衝突するリスクがあるということです。また、既存のサフィックス (F、L、ULL など) とも衝突します。ユーザー定義のリテラルの論理的根拠の 1 つは、新しい型 (たとえば、10 進数など) を、サフィックス d を持つリテラルを含む純粋なライブラリ拡張として定義できることです。 df、dl。

次に、スタイルと読みやすさの問題があります。個人的には、接尾辞 1234_3 を見失うと思います。多分そうでないかもしれません。

最後に、Ada や Ruby のように _ を数字のリテラル区切り記号にするというアイデアが標準には採用されませんでした (しかし、私は好きです)。したがって、たとえば 123_456_789 を使用して、数千を視覚的に区切ることができます。それが通過した場合、あなたの接尾辞は壊れます。

于 2011-04-27T03:11:14.350 に答える
1

「できる」対「かもしれない」。
can は能力を表し、may は許可を表します。

_ の後に数字が続くユーザー定義のリテラル接尾辞を開始する権限がない理由はありますか?

パーミッションは、コーディング標準またはベスト プラクティスを意味します。あなたが提供する例は、_\d正しく使用された場合（数値ベースを示すために）接尾辞がうまくいくことを示しているようです。残念ながら、この新しい言語機能をまだ誰も経験していないため、あなたの質問には十分に考え抜かれた答えがありません。

明確にするために、 から始めることがuser-defined literal suffixes でき_\dます。

于 2011-04-25T15:04:28.103 に答える
1

フォームの識別子の先例は、(§20.8.9.1.3)_<number>の関数引数プレースホルダー オブジェクト メカニズムでstd::placeholdersあり、そのようなシンボルの実装定義の数を定義します。

これは、ユーザーが#defineそのフォームの識別子を取得できないことを意味するため、良いことです。§17.6.4.3.1/1:

標準ライブラリ ヘッダーを含む翻訳単位は、標準ライブラリ ヘッダーで宣言された #define または #undef 名を使用してはなりません。

ユーザー定義のリテラル関数の名前はoperator "" _123、単に_123ではなく であるため、using namespace std::placeholders;.

operator "" _baseconvただし、私の 2¢ は、 を使用して、リテラル内のベースをエンコードする方がよいということです"123123_4"_baseconv。

編集： ヨハネスの（削除された）回答を見ると、実装によって_123マクロとして使用される懸念がある可能性があります。これは確かに理論の領域です。このようなプリプロセッサの使用によって実装が得られるものはほとんどないからです。さらに、私が間違っていなければ、これらのシンボルをそれ自体ではなく で非表示にする理由は、Boost Bind を含めるなどして、そのような名前がユーザーによって使用される可能性が高いためです (名前付きの名前空間)。std::placeholdersstd

トークンは実装でグローバルに使用するために予約されておらず (17.6.4.3.2)、それらの使用には先例があるため、少なくとも、forward.

于 2011-04-26T20:10:19.193 に答える