C ++ 14 자리 구분자에 공백 문자가 선택되지 않은 이유는 무엇입니까?

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";

대신, 우리는 '내가 아는 어떤 쓰기 시스템에서도 숫자 구분 기호로 사용되지 않는 아포스트로피 ( )를 얻습니다 .

단순한 공백 대신 아포스트로피를 선택한 이유가 있습니까?

---

_{^† 텍스트 내에서 이러한 모든 언어는 쉼표가 다른 원자 적 문장을 "분리"한다는 개념을 유지하기 때문에 마침표는 문장을 "종료"하는 기능을합니다. 적어도 저에게는 이것은 a와 매우 유사합니다. 쉼표는 숫자의 정수 부분을 "분리"하고 마침표를 "종료"하여 분수 입력을 준비합니다.}

---

Bjarne 자신이 공백을 구분 기호로 제안했지만 다음과 같은 이전 논문 인 n3499가 있습니다 .

이 접근법은 하나의 일반적인 서체 스타일과 일치하지만 일부 호환성 문제가 있습니다.

• pp-number 의 구문과 일치하지 않으며 최소한 해당 구문을 확장해야합니다.
• 더 중요한 것은 [af] 범위의 16 진수 숫자가 공백 다음에 올 때 구문 상 모호함이 있다는 것입니다. 전처리 기는 공백 이후에 기호 대체를 수행할지 여부를 알지 못합니다.
• "단어"를 잡는 편집 도구의 안정성이 떨어질 수 있습니다.

다음 예가 주요 문제라고 생각합니다.

const int x = 0x123 a;

제 생각에는이 근거가 상당히 약합니다. 나는 그것을 깨는 실제 사례를 아직도 생각할 수 없다.

"편집 도구"의 이론적 근거는 1'234기본적으로 인류에게 알려진 모든 구문 형광펜 (예 : 위의 질문에서 Markdown이 사용하는 구문)을 깨뜨리고 해당 형광펜의 업데이트 된 버전을 구현하기가 훨씬 더 어렵 기 때문에 더욱 나쁩니다 .

그래도 좋든 나쁘 든 이것이 대신 아포스트로피를 채택하게 된 이유입니다.

---

공백을 사용하지 않는 명백한 이유는 새 줄도 공백이고 C ++는 모든 공백을 동일하게 처리하기 때문입니다. 그리고 손으로 임의의 공백을 구분 기호로 허용하는 언어를 모릅니다.

아마도 유니 코드 0xA0 (간단하지 않은 공백)을 사용할 수 있습니다. 이것은 조판시 가장 널리 사용되는 솔루션입니다. 그러나 두 가지 문제가 있습니다. 첫째, 기본 문자 집합에 있지 않고 둘째, 시각적으로 구별되지 않습니다. 일반 편집기에서 텍스트를 보는 것만으로는 공간이 아님을 알 수 없습니다.

그 외에도 선택의 여지가 많지 않습니다. 쉼표는 이미 합법적 인 토큰이므로 사용할 수 없습니다 ( 1,234현재 합법적 인 C ++, 의미 234). 그리고 법적 코드에서 발생할 수있는 상황에서 a[1,234]. 실제로 이것을 사용하는 실제 코드를 상상할 수는 없지만 아무리 어리석은 것과 상관없이 법적인 프로그램이 의미를 조용히 변경해서는 안된다는 기본 규칙이 있습니다.

비슷한 고려 사항은 그것도 _사용할 수 없다는 것을 의미 합니다. 이 경우 #define _234 * 2, 다음 a[1_234]자동으로 코드의 의미를 변경합니다.

를 선택하는 것이 특히 기쁘다 고 말할 수는 없지만 '적어도 일부 유형의 텍스트에서는 유럽 대륙에서 사용된다는 장점이 있습니다. (예를 들어, 일반적인 실행 텍스트에서 독일어는 대부분의 다른 언어와 마찬가지로 점 또는 비 구분 공백을 사용하지만 독일어로 본 것을 기억하는 것 같습니다. 그러나 아마도 스위스 독일어 일 수도 있습니다.) 문제 '는 구문 분석입니다. ; 시퀀스 '1'는 이미 합법적입니다 '123'. 그래서 같은 1'234것은1, 문자 상수의 시작이 뒤 따릅니다. 결정을 내리기 위해 얼마나 앞을 내다 봐야할지 모르겠습니다. 적분 상수 다음에 문자 상수가 올 수있는 합법적 인 C ++ 시퀀스가 ​​없으므로 합법적 인 코드를 깨는 데 문제가 없지만 어휘 스캔이 갑자기 컨텍스트에 크게 의존하게됨을 의미합니다.

(귀하의 의견과 관련하여 : 소수점 또는 천 단위 구분 기호를 선택하는 데 논리가 없습니다. 예를 들어 소수점 구분 기호는 확실히 마침표가 아닙니다. 임의의 규칙 일뿐입니다.)

---

에서 위키 , 우리는 좋은 예제를 가지고 :

auto floating_point_literal = 0.000'015'3;

여기에 .연산자가 있고 다른 연산자를 만나면 제 눈은 공백이 아닌 쉼표 나 다른 것과 같이 보이는 것을 기다릴 것입니다.

따라서 아포스트로피는 공백보다 여기에서 훨씬 낫습니다.

공백을 사용하면

auto floating_point_literal = 0.000 015 3;

아포스트로피의 경우만큼 옳지 않은 것 같습니다.

---

Albert Renshaw의 대답 과 같은 정신으로 나는 아포스트로피가 궤도의 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가 언급하는 문자열 연결과 같이 많은 일에 사용됩니다. 아포스트로피와는 달리이 경우 숫자를 구분하는 데 사용되는 사람에게 명확 해집니다.

코드 줄이 많아지면 가독성이 향상 될 것이라고 생각하지만 그것이 그들이 그것을 선택한 이유는 의심 스럽습니다.

---

공백에 대해 다음과 같은 C 질문을 살펴볼 가치가 있습니다 .

The language doesn't allow int i = 10 000; (an integer literal is one token, the intervening whitespace splits it into two tokens) but there's typically little to no expense incurred by expressing the initializer as an expression that is a calculation of literals:

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

---

It is true I see no practical meaning to:

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

so digits might be merged without real ambiguity but what about an hexadecimal number?

0 x 1 a B 2 3

There is no way to disambiguate from a typo doing so (normally we should see an error)

---

I would assume it's because, while writing code, if you reach the end of a "line" (the width of your screen) an automatic line-break (or "word wrap") occurs. This would cause your int to get split in half, one half of it would be on the first line, the second half on the second... this way it all stays together in the event of a word-wrap.

---

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

Commenting does not hurt:

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

Binary strings can be hard to parse:

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.

A macro for consideration:

#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);

---

It has to do with how the language is parsed. It would have been difficult for the compiler authors to rewrite their products to accept space delimited literals.

Also, I don't think seperating digits with spaces is very common. That i've seen, it's always non-whitespace characters, even in different countries.

참고URL : https://stackoverflow.com/questions/27767781/why-was-the-space-character-not-chosen-for-c14-digit-separators