C ++ 언어 디자이너가 키워드를 계속 재사용하는 이유는 무엇입니까?

C ++ 언어 디자이너가 키워드를 계속 재사용하는 이유는 무엇입니까?

---

더 많은 키워드를 추가하는 대신 짧은 키워드를 재사용하고 문맥에 따른 의미를 추가하는 것을 선호하는 주된 주장은 무엇입니까?

이미 제안 된 새 키워드를 사용하고있을 수있는 기존 코드를 손상시키지 않으려는 것뿐입니까? 아니면 더 깊은 이유가 있습니까?

C ++ 11의 새로운 "열거 형 클래스"는 이것에 대해 생각하게 만들었지 만 이것은 일반적인 언어 디자인 질문입니다.

---

이미 제안 된 새 키워드를 사용하고있을 수있는 기존 코드를 손상시키지 않으려는 것뿐입니까? 아니면 더 깊은 이유가 있습니까?

아니, 그게 이유야.

정의에 따라 키워드는 소스에서 발생하는 모든 위치에서 항상 키워드로 간주되므로 다른 목적으로 사용할 수 없습니다. 무언가를 키워드로 만들면 해당 토큰을 변수, 함수 또는 유형 이름으로 사용할 수있는 코드가 손상됩니다.

은 C위원회는 예를 들어, _Reserved 이름을 사용하여 새로운 키워드를 다른 접근 방식을 가지고 추가 _Atomic, _Bool다음 그들이 새로운 헤더 (추가 <stdatomic.h>, <stdbool.h>당신은 이름을 얻을 수있는 헤더를 포함할지 여부를 선택할 수 있도록, 더 좋은 매크로를) atomic또는 bool하지만, 자동으로 선언되지 않으며 이미 해당 이름을 사용하는 코드를 중단하지 않습니다.

C ++위원회는 매크로를 좋아하지 않고 적절한 키워드가되기를 원합니다. 따라서 기존 키워드 (예 :)를 재사용 auto하거나 상황에 따른 "키워드"(실제로 키워드는 아니지만 "특별한 의미를 가진 식별자")를 추가합니다. 그들은 그렇게 할 수 와 같은 다른 것들에 사용될 수 override) 또는 같은 (사용자 코드와 충돌 할 가능성이 이상한 철자를 사용하는 decltype대신에 광범위하게 지원의 typeof확장).

---

일부 오래된 언어에는 키워드가 전혀 없었습니다. 특히 PL / 1 은

IF IF=THEN THEN BEGIN;
  /* some more code */
END;

합법적 인 코드 였지만 완전히 읽을 수 없었습니다. ( 코드의 원저자조차도 몇 달 후에 읽을 수있는 완전히 비밀스러운 쓰기 중심 프로그래밍 언어 의 예로 APL 을 살펴보십시오 .)

C 및 C ++ 언어 계열에는 언어 사양에 정의 된 키워드 세트가 있습니다. 그러나 수십억 개의 레거시 소스 코드 라인이있는 매우 널리 사용되는 언어가 있습니다. 당신 (또는 그들의 표준화위원회)이 새로운 키워드를 추가하면, 기존 프로그램과 충돌 할 가능성이 있으며, 당신이 추측하고 다른 사람들은 이것이 나쁘다고 대답했습니다. 따라서 표준이 예를 들어 enum_class새 키워드로 추가 된 경우 누군가 이미이를 식별자로 사용했을 가능성이 있으며 해당 엔터티는 불행 할 것입니다 (새로운 C ++ 표준을 채택 할 때 코드를 변경해야 함).

또한 C ++는 느리게 구문 분석되는 것으로 널리 알려져 있습니다 (특히 표준 헤더 <vector>가 수십만 줄의 소스 코드를 가져오고 모듈이 아직 C ++에없고 구문이 매우 모호하기 때문에). 새로운 구문을 처리하는 것은 큰 문제가 아닙니다 (어쨌든 C ++ 구문 분석은 항상 끔찍했습니다). 예를 들어 GCC 커뮤니티는 새로운 C ++ 기능보다 새로운 최적화에 대해 훨씬 더 열심히 노력하고 있습니다 (분명히 C ++ 표준 라이브러리의 최신 기능은 새로운 구문을 구문 분석하는 것보다 많은 작업이 필요합니다). C ++ 03에서 C ++ 11로 이동하더라도 큰 도약이었고 C ++ 프론트 엔드에서 많은 작업이 필요했습니다. 이것은 C ++ 11에서 C ++ 14로 점프하는 경우에는 사실이 아닙니다.

일부 다른 언어 (예 : Common Lisp 와 같은 Lisp의 일부 방언 및 a 또는 매크로를 재정의 할 수있는 일부 Scheme , 이러한 동음 이어 언어의 매크로 는 AST에서 작동하기 때문에 C 의 조잡한 텍스트 대체 메커니즘 과 매우 다릅니다. 또는 C ++ ...) 기존 키워드의 재정의를 허용합니다. 위생 매크로에 대해서도 읽어보십시오 . 그러나 이로 인해 몇 달 후 소스 코드를 이해하기 어려울 수 있습니다.letif

---

주로 키워드를 추가하면 다른 컨텍스트에서이 키워드를 사용하는 기존 코드가 깨지기 때문이라고 생각합니다.

---

이미 제안 된 새 키워드를 사용하고있을 수있는 기존 코드를 손상시키지 않으려는 것뿐입니까? 아니면 더 깊은 이유가 있습니까?

정의에 따라 키워드는 다른 곳에서는 사용할 수없는 특수 토큰입니다. 결과적으로 키워드를 도입하면 지정된 철자와 식별자를 사용하는 코드가 손상됩니다.

일부 언어에서는 문맥 키워드 라는 용어를 사용하여 특정 문맥에서 키워드로만 해석되는 철자를 나타냅니다. 이전에이 컨텍스트에서 "와일드"식별자를 사용할 수 없었던 경우 컨텍스트 키워드의 도입으로 기존 코드가 손상되지 않을 것입니다. 예를 들어 함수 시그니처에서 닫는 괄호 바로 뒤에는 식별자가 표시 될 수 없기 때문에 여기에서 소위 컨텍스트 키워드 (예 : override또는 final)를 도입 할 수 있습니다 .

반면에 이전에 식별자가 허용 된 곳에서는 키워드를 추가하면 위험이 따릅니다. 예를 들면 :

• struct H { my_type f; enum { g }; };: enum class새 키워드가 아닌 의 사용은 이 컨텍스트에서 새 단어가 데이터 멤버 선언의 시작으로 잘못 인식 될 수 있기 때문입니다. 키워드 만 모호하지 않으며 (LL (1)에서) 새 키워드를 도입하면 코드가 손상 될 수 있습니다.
• void h() { my_type f; auto x = g(); }: auto새 키워드가 아닌 의 사용은 새 단어가 기존 유형과 충돌 할 수 있기 때문입니다. 이것은 C 에서 이미이 위치 에서 사용할 수있는 키워드 int였지만 (기본값은 type) 그 의미가 변경 되었기 때문에 여전히 놀라운 선택입니다 (사용할 확률이 낮기 때문입니다).

일부에서 언급했듯이 언어는 키워드없이 완전히 설계되거나 (Haskell이 매우 가깝게 제공됨) 키워드를 원활하게 도입 할 수있는 방식으로 만들 수 있습니다 (예를 들어 모든 선언이 이미 키워드로 시작되는 경우 새 키워드를 도입하면 충돌 할 수 없습니다.) ). 그것은 그렇게 만들어지지 않은 C와 C ++, 그리고 실제로 많은 C와 같은 언어보다 발생합니다.

---

"적을수록 더 많다"라는 잘못된 열정. 더 적은 키워드를 사용하면 프로그래머가 더 적게 배워야하고 더 빨리 생산성을 높일 수 있다고 (잘못) 생각됩니다. 그러나 이것은 구문에 대한 혼란을 야기 할뿐입니다.

"진짜 Perl 프로그래머는 시각적으로 구별되는 것을 선호합니다." ---- 래리 월

즉, 하나의 작업에만 키워드를 사용하십시오.

참고 URL : https://stackoverflow.com/questions/32757571/why-do-the-c-language-designers-keep-re-using-keywords