C#에서 `short int` 데이터 유형에 리터럴 수정자가 없는 이유는 무엇입니까?

프로그래밍 언어에서 특정 데이터 유형에 리터럴 수정자가 없는 이유

C#과 같은 프로그래밍 언어는 일관성과 논리적 설계를 위해 노력하지만 다음과 같은 경우가 있습니다. 특정 데이터 유형에는 리터럴 수정자가 없을 수 있습니다. 이는 이러한 차이의 원인에 대한 의문을 제기합니다.

사례 연구: C#의 long int와 short int

C#의 long int와 short int의 예를 생각해 보세요. . 전자는 문자 그대로의 수식어('L' 또는 'l')를 갖고 있는 반면, 후자는 그렇지 않습니다. 이는 질문을 촉발합니다: 왜 이러한 분리가 필요한가?

부재 방어

표준적인 주장은 리터럴 수식어와 같은 기능이 비용보다 이점이 클 때 도입된다는 것입니다. short int의 경우 int의 기존 기능을 고려하여 그 필요성을 정당화할 책임은 제안자에게 있습니다.

long int의 리터럴 수정자 정당성

정수 계산의 압도적인 대부분은 32비트 부호 있는 정수(int) 범위 내에 속합니다. 따라서 C#에서는 산술 연산에 대해 이 표현을 기본으로 사용하여 정수 리터럴에 대한 '1' 접미사를 직관적으로 만듭니다.

그러나 계산이 이 범위를 넘어 확장되거나 특정 비트 패턴이 필요한 경우 'L' 및 'U와 같은 수정자 ' 놀러오세요. 이는 각각 64비트 긴 정수 또는 부호 없는 정수를 사용하려는 의도를 명확하게 나타냅니다.

짧은 int를 사용하지 않는 이유는 무엇입니까?

long int와 달리 두 가지 이유가 있습니다. 왜 short int에 리터럴이 부족한가? 수정자:

1. 호환성: 정수 리터럴은 문제 없이 short int에 합법적으로 할당될 수 있습니다.
2. 산술 제한: 산술은 명시적으로 사용되지 않습니다. C#에서 Shorts로 수행되었습니다. 대신, 계산 중에 short가 int로 승격됩니다. 왜냐하면 대부분의 연산이 정수 범위에 맞고 short 연산이 최신 하드웨어에서는 비효율적일 수 있기 때문입니다.

결론

요약하자면, 이점이 분명한 유형에 대해 리터럴 수식자가 제공됩니다. int의 경우 기본 표현이 대부분의 경우에 적합한 반면, long int 및 unsigned 정수는 특정 요구 사항을 해결합니다. Short int는 이미 해당 기능을 수행하고 언어의 명시적 산술에 사용되지 않기 때문에 수정자가 없습니다.

위 내용은 C#에서 `short int` 데이터 유형에 리터럴 수정자가 없는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!