'uint'및 'short'데이터 유형이 표준 int (32)보다 더 적합한 경우는 무엇입니까?

나는 그들이 나타낼 수있는 용량과 가치의 차이를 이해하지만 그것이 적절한 지 여부에 관계없이 사람들이 항상 사용 하는 것처럼 보입니다 Int32. uint음수가 될 수없는 값 (데이터베이스 레코드의 ID를 나타낼 수 있음)을 설명 할 때 많은 시간이 걸리더라도 서명되지 않은 버전 ( ) 을 사용 하는 사람은 없습니다. 또한 short/Int16필요한 가치의 용량에 관계없이 아무도 사용하지 않는 것 같습니다 .

객관적으로 더 나은 사용의 경우,이 경우는 uint또는 short/Int16그렇다면, 그들은 어떤입니까?

나는 당신이 적분 유형을 올바르게 사용하는 사람들을 위해 일하지 않은 당신의 경험에 의해 색을 입힌 관점을 언급하고 있다고 생각합니다. 이것은 흔한 일이지만 사람들이 일반적으로 올바르게 사용하는 것은 저의 경험이었습니다.

이점은 유형이 유선 또는 디스크로 전송되는지 여부에 따라 메모리 공간 및 CPU 시간이며 IO 공간 일 수도 있습니다. 부호없는 유형은 컴파일러 검사를 통해 불가능한 특정 작업을 수행하지 않고 사용 가능한 범위를 확장하는 동시에 필요한 경우 성능을 높이기 위해 더 작은 크기를 유지합니다.

올바른 사용자가 예상하는대로 사용하는 것이다 - 당신이 알고 언제 확실히는 당신이 그들을 사용할 수 있습니다 영구적으로 (어떻게 확신없이 제한하거나하지 않습니다 나중에 후회).

• 절대로 부정적이지 않은 것을 표현하려는 경우 public uint NumberOfPeople부호없는 유형을 사용하십시오.
• 합리적으로 255 ( public byte DamagedToothCount) 보다 클 수없는 것을 표현하려는 경우 바이트를 사용하십시오.
• 합리적으로 255보다 클 수 있지만 수천의 숫자는 절대로 표현하지 않으 려면 짧은 ( public short JimmyHoffasBankBalance)을 사용하십시오.
• 수십만, 수백만이 될 수 있지만 수십억에 도달 할 가능성이없는 것을 표현하려는 경우 int ( public int HoursSinceUnixEpoch)를 사용하십시오.
• 이 숫자가 무한히 큰 값을 가질 수 있거나 수십억을 가질 수 있다고 생각하지만 수십억을 확신 할 수 없다면 최선의 방법은 무엇입니까? 충분히 길지 않으면 흥미로운 문제가 발생하여 임의의 정밀도 숫자 ( public long MyReallyGreatAppsUserCountThisIsNotWishfulThinkingAtAll)를 살펴 봐야합니다 .

이 추론은 부호있는, 부호없는, 다양한 크기의 유형 등을 선택할 때 전체적으로 사용될 수 있으며 실제로 표현하는 데이터의 논리적 진실에 대해서만 생각하면됩니다.

그것을 사용하는 것이 좋습니다 어디 물론, 경우가있다 uint거나 short또는 Int16. 데이터 범위가 해당 변수 유형의 제약 조건에 맞는다는 것을 알고 있으면 해당 유형을 사용해도됩니다.

메모리가 제한된 환경이나 대량의 객체를 처리 할 때는 가장 작은 크기 변수를 사용하는 것이 좋습니다. 예를 들어, ints 대 shorts 의 백만 요소 배열의 경우 크기에 큰 차이가 있습니다 .

종종 다음 중 하나 이상의 이유로 인해 실제 코드에서 발생하지 않습니다.

• 데이터 제약은 미리 알려지지 않았다
• 데이터 제약 조건이 확실하지 않거나 변경 될 가능성이있는 것으로 확인되었습니다
• 더 넓은 데이터 범위에서 함수를 재사용 할 수있는 희망이있었습니다.
• 개발자는 제약 조건을 생각하는 데 시간이 걸리지 않았습니다.
• 더 작은 변수 유형을 사용하여 메모리 절약은 중요하지 않았습니다.

더 많은 이유가있을 수 있지만, 그 결과는 다음과 같습니다. 다른 변수 유형을 결정하고 사용하는 데 걸리는 시간은 그렇게하는 데 충분한 이점을 제공하지 못했습니다.

C에서 정수 승격을 포함하지 않는 컨텍스트 에서 부호없는 값은 "래핑"추상 대수 고리의 멤버로 작동하도록 지정되었습니다. 따라서 XY는 X에 추가 될 때 X를 생성하는 고유 한 값을 생성합니다. ), 부호있는 정수 유형은 계산이 특정 범위 내에있을 때 정수처럼 동작하는 것으로 지정되었으며 계산이 그 범위를 넘어 서면 아무것도 할 수 없었습니다. 그러나 C #의 숫자 의미론은 완전히 다릅니다. 확인 된 숫자 컨텍스트 내에서 부호있는 유형과 부호없는 유형 모두 계산이 범위 내에 머무르면 정수처럼 동작 OverflowException하고 그렇지 않은 경우에는 던져집니다 . 확인되지 않은 상황에서 둘 다 대수 고리처럼 동작합니다.

Int32컴팩트 스토리지 또는 운송을 위해 물건을 포장하거나 포장을 풀어야 할 때보 다 작은 데이터 유형을 사용하는 것이 일반적으로 가치있는 유일한 시간 입니다. 50 억 개의 양수를 저장해야하고 모두 0에서 100 사이의 범위에 있으면 4 개가 아닌 1 바이트를 사용하면 1.5GB의 저장 공간이 절약됩니다. 크게 절약됩니다. 그러나 코드 조각에 총 수백 개의 값을 저장해야하는 경우 각 값을 4 개가 아닌 1 바이트로 만들면 약 600 바이트가 절약됩니다. 아마도 귀찮게 할 가치가 없습니다.

부호없는 유형과 관련하여 정보 교환을 수행하거나 숫자를 조각으로 나눌 때 실제로 유용한 유일한 시간입니다. 예를 들어 96 비트 정수에서 수학을 수행해야하는 경우 부호없는 정수 그룹보다 부호없는 32 비트 정수 3 개의 그룹에서 계산을 수행하는 것이 훨씬 쉽습니다. 그렇지 않으면 부호있는 32 비트 또는 64 비트 값의 범위가 적절하지 않은 상황은 많지 않지만 같은 크기의 부호없는 값으로 충분합니다.

일반적으로 서명되지 않은 형식은 불쾌한 방식으로 오버플로되기 때문에 사용하지 않는 것이 좋습니다. x = 5-6코드에서 갑자기 시한 폭탄입니다. 한편 부호없는 유형의 이점은 단일 정밀도의 단일 비트로 귀결되며, 그 비트가 가치가 있다면 더 큰 유형을 사용해야합니다.

더 작은 유형이 의미가있는 유스 케이스가 있지만 메모리 사용에 대해 염려하거나 전송 또는 캐시 효율성을 위해 데이터를 팩킹해야하는 경우 또는 다른 여러 가지 우려가없는 경우 일반적으로 더 작은 유형을 사용하면 이점이없는 경우가 있습니다. . 또한 많은 아키텍처에서 실제로 이러한 유형을 사용하는 것이 느리 므로 실제로 적은 비용을 부과 할 수 있습니다.

특히 .NET 유형을 처리 할 때 질문에 대해 잊어 버리거나 접할 수있는 것은 CLS Compliance 입니다. .NET Framework에 구축 된 모든 언어에서 모든 유형을 사용할 수있는 것은 아닙니다.

C # 이외의 언어로 소비되는 코드를 작성하고 해당 코드가 가능한 한 많은 .NET 언어와 상호 운용되도록하려면 유형 사용을 CLS 규격 인 언어로 제한해야합니다.

예를 들어 초기 버전의 VB.NET (7.0 및 7.1)은 부호없는 정수 ( UInteger)를 지원하지 않았습니다 .

http://msdn.microsoft.com/en-us/library/aa903459(v=vs.71).aspx

부호없는 정수는 CLS 규격이 아니므로 클래스 라이브러리 소비자가 누구인지 확실하지 않은 경우주의해서 사용해야합니다.