web-dev-qa-db-ja.com

C ++ 14の桁区切り文字にスペース文字が選択されなかったのはなぜですか？

C++ 14の時点で、 n3781 のおかげで（それ自体はこの質問に答えていません）、次のようなコードを書くことができます。

const int x = 1'234; // one thousand two hundred and thirty four

目的は、次のようなコードを改善することです。

const int y = 100000000;

より読みやすくします。

アンダースコア（_）文字は、C++ 11でユーザー定義のリテラルとコンマ（,）ローカライズの問題がある-多くのヨーロッパ諸国が困惑している† これを小数点区切り記号として使用し、コンマ演算子と競合しますが、実際のコードは、たとえば1,234,567。

とにかく、より良い解決策はスペース文字のようです：

const int z = 1 000 000;

これらの隣接する数値リテラルトークンは、文字列リテラルと同様に、プリプロセッサによって連結できます。

const char x[5] = "a" "bc" "d";

代わりに、アポストロフィ（'）、桁区切り記号として認識しているどの書記体系でも使用されていません。

単純なスペースの代わりにアポストロフィが選択された理由はありますか？

† それらの言語はすべて、テキスト内で、文を「終了」するために機能するピリオドで、そうでなければアトミックな文を「分解」するというカンマの概念を維持しているため、困惑しています。数の整数部分を「分解」し、分数入力の準備ができている期間を「終了」します。

c++language-lawyerc++14digit
63
Lightness Races in Orbit

以前の論文 n3499 があります。Bjarne自身が区切り文字としてスペースを提案したにもかかわらず、

このアプローチは1つの一般的な活版印刷スタイルと一致していますが、互換性の問題がいくつかあります。

  • pp-numberの構文とは一致せず、その構文を最小限に拡張する必要があります。
  • さらに重要なことは、[a-f]の範囲の16進数字がスペースに続く場合、構文上のあいまいさが生じることです。プリプロセッサは、スペースの後からシンボル置換を実行するかどうかを知りません。
  • 「単語」を取得する編集ツールの信頼性が低下する可能性があります。

以下の例が注目される主な問題だと思います。

const int x = 0x123 a;

私の意見では、この理論的根拠はかなり弱いです。私はまだそれを打破する実世界の例を考えることができません。

「編集ツール」の理論的根拠は、1'234は、基本的に人類が知っているすべての構文ハイライター（たとえば、上記の質問自体でMarkdownが使用したもの）を破壊し、上記ハイライターの更新バージョンを実装するのをはるかに困難にします。

それでも、良くも悪くも、これが代わりにアポストロフィの採用に至った根拠です。

35
Lightness Races in Orbit

wiki から、ニースの例があります：

auto floating_point_literal = 0.000'015'3;

ここには、.演算子を使用し、別の演算子を使用する場合は、空白ではなくコンマや何かなどの目に見えるものを待ちます。

そのため、ここではアポストロフィは空白よりもはるかに優れています。

空白があると、

auto floating_point_literal = 0.000 015 3;

アポストロフィの場合ほど適切ではありません。

Albert Renshawの答え と同じ精神で、アポストロフィはOrbitのLightness Racesが提案するスペースよりも明確だと思います。

type a = 1'000'000'000'000'000'544'445'555;
type a = 1 000 000 000 000 000 544 445 555;

OPはアポストロフィとは異なり、OPが言及する文字列の連結など、多くのことにスペースが使用されます。

コードの行が多くなると、これが読みやすさを改善すると思いますが、それが彼らがそれを選んだ理由だとは思いません。

スペースについては、このC question を見てみる価値があります。

この言語ではint i = 10 000;（整数リテラルは1つのトークンであり、空白を挟むことで2つのトークンに分割されます）が、通常、リテラルの計算である式として初期化子を表現することにより、負担はほとんどまたはまったくありません。

int i = 10 * 1000; /* ten thousand */

10
gsamaras

私には実際的な意味がないと思います：

if (a == 1 1 1 1 1) ...

したがって、数字は実際のあいまいさなしにマージされる可能性がありますが、16進数はどうですか？

0 x 1 a B 2 3

タイプミスを明確にする方法はありません（通常、エラーが表示されるはずです）

9
hlide

コードを書いているときに、「行」（画面の幅）の最後に到達すると、自動改行（または「ワードラップ」）が発生するためだと思います。これにより、intが半分に分割され、その半分が最初の行に、後半が2番目に分割されます。このように、Word-wrap。

5
Albert Renshaw
float floating_point_literal = 0.0000153;   /* C, C++*/

auto floating_point_literal = 0.0000153;    // C++11

auto floating_point_literal = 0.000'015'3;  // C++14

コメントは問題ありません：

/*  0. 0000 1530 */ 
float floating_point_literal = 0.00001530;

バイナリ文字列は解析が難しい場合があります。

long bytecode = 0b1111011010011001; /* gcc , clang */  

long bytecode = 0b1111'0110'1001'1001;  //C++14
// 0b 1111 0110 1001 1001  would be better, really.
// It is how humans think.

検討のためのマクロ：

#define B(W,X,Y,Z)    (0b##W##X##Y##Z)
#define HEX(W,X,Y,Z)  (0x##W##X##Y##Z)
#define OCT(O)        (0##O)



long z = B(1001, 1001, 1020, 1032 ); 

// result :  long z = (0b1001100110201032);

 long h = OCT( 35); 

// result :  long h  = (035); // 35_oct => 29_dec

 long h = HEX( FF, A6, 3B, D0 ); 

// result :  long h  = (0xFFA6BD0);
1
Chris Reid