uint_fast32_t보다 uint32_t가 선호되지 않는 이유는 무엇입니까?

uint_fast32_t보다 uint32_t가 선호되지 않는 이유는 무엇입니까?

인 것 같다uint32_t보다 훨씬 더 널리 퍼지고 있다uint_fast32_t(이것이 일화적인 증거라는 것을 알고 있습니다).하지만 그건 직관에 어긋나는 것 같아요.

구현의 용도를 보면 거의 항상uint32_t필요한 것은 최대 4,294,967,295(통상 65,535 ~4,294,967,295 사이의 하한)의 값을 유지할 수 있는 정수입니다.

그럼 좀 이상한데?uint32_t'syslog 32bits' 보증이 필요하지 않으며 'syslog available >= 32bits' 보증이 필요 없기 때문에uint_fast32_t딱 맞는 생각인 것 같아요게다가, 통상, 실장되고 있는 동안은,uint32_t실제로 존재한다고 보장되지 않습니다.

그럼 왜?uint32_t선호되는가?단순히 더 잘 알려진 제품입니까, 아니면 다른 제품보다 기술적 이점이 있습니까?

uint32_t는,¹ 그것을 서포트하는 모든 플랫폼에서 거의 같은 속성을 가지는 것을 보증합니다.

uint_fast32_t님은 다른 시스템에서의 동작에 대해 거의 보증하지 않습니다.

다음 플랫폼으로의 전환 시uint_fast32_t사이즈가 다릅니다.는 모든 코드를 사용합니다.uint_fast32_t다시 테스트하고 검증해야 합니다.모든 안정성에 관한 전제조건은 무효가 됩니다.전체 시스템이 다르게 작동합니다.

코드를 쓸 때, 당신은 심지어 당신의 코드에 접근하지 못할 수도 있습니다.uint_fast32_t32비트가 아닌 시스템입니다.

uint32_t다르게 동작하지 않습니다(각주 참조).

정확성이 속도보다 더 중요하다.따라서 섣부른 수정은 섣부른 최적화보다 더 나은 계획입니다.

시스템 코드를 작성하고 있을 때uint_fast32_t64비트 이상이면 두 경우 모두 코드를 테스트하여 사용할 수 있습니다.필요와 기회를 모두 배제하고 그렇게 하는 것은 좋지 않은 계획이다.

마침내.uint_fast32_t임의의 기간 동안 저장할 경우 또는 인스턴스 수가 다음보다 느릴 수 있습니다.uint32단순히 캐시 크기 문제와 메모리 대역폭이 원인입니다.오늘날 컴퓨터는 CPU보다 메모리 바인딩이 훨씬 더 많습니다.uint_fast32_t메모리 오버헤드를 고려한 후에는 분리 시 속도가 더 빨라질 수 있습니다.

---

¹ @chux가 코멘트에서 언급했듯이unsigned보다 크다uint32_t, 산술:uint32_t통상적인 정수 프로모션을 거칩니다.그렇지 않으면 그대로입니다.uint32_t이것은 버그를 일으킬 수 있습니다.완벽한 것은 없다.

왜 많은 사람들이uint32_t보다는uint32_fast_t?

주의: 이름이 잘못 지정됨uint32_fast_t그래야 한다uint_fast32_t.

uint32_t보다 엄격한 사양을 가지고 있다uint_fast32_t그 때문에, 보다 일관된 기능이 실현됩니다.

---

uint32_t장점:

• 다양한 알고리즘이 이 유형을 지정합니다.IMO - 사용하는 가장 좋은 이유.
• 정확한 폭과 범위를 알고 있습니다.
• 이런 유형의 어레이는 낭비가 없습니다.
• 오버플로우가 있는 부호 없는 정수 산술이 더 예측하기 쉽습니다.
• 다른 언어의 32비트 타입의 범위와 산술이 거의 일치합니다.
• 패딩 안 했어.

uint32_t단점:

• 항상 이용할 수 있는 것은 아닙니다(2018년에는 거의 없습니다).
  예: 8/16/32비트 정수가 없는 플랫폼(9/18/36비트, 기타).
  예: 비2의 보완을 사용하는 플랫폼.구 2200

uint_fast32_t장점:

• 언제든지 이용 가능.
  이것에 의해, 신구 모두, 항상 고속/최소 타입을 사용할 수 있습니다.
• 32비트 범위를 지원하는 "Fastest" 유형.

uint_fast32_t단점:

• 범위는 최소한으로 알려져 있을 뿐입니다.예를 들어 64비트 타입일 수 있습니다.
• 이 타입의 어레이는 메모리 낭비가 될 수 있습니다.
• 모든 답변(처음에도 해당), 게시물 및 댓글에 잘못된 이름이 사용됨uint32_fast_t많은 사람들이 이런 타입을 필요로 하지 않고 사용하고 있는 것 같습니다.이름도 제대로 못 썼어요!
• 패딩 가능 - (희귀).
• 일부의 경우, 「가장 빠른」타입이 실제로는 다른 타입이 될 수 있습니다.그렇게uint_fast32_t는 1차 근사치일 뿐입니다.

결국, 가장 좋은 것은 코딩 목표에 달려 있습니다.휴대성이 매우 넓거나 퍼포먼스가 뛰어난 기능을 위해 코딩하지 않는 한,uint32_t.

---

이러한 타입을 사용할 때 또 다른 문제가 있습니다.이러한 타입의 순위는int/unsigned

아마도uint_fastN_t계급이 될 수 있다unsigned이것은 특정되지 않았지만 특정 테스트 가능한 조건입니다.

따라서,uintN_t보다 가능성이 높다uint_fastN_t좀 더 좁혀서unsigned즉, 이 코드는uintN_t수학은 정수 승진의 대상이 될 가능성이 높다.uint_fastN_t휴대성에 관해서입니다.

이러한 우려와 함께: 휴대성의 이점uint_fastN_t선택한 산술 연산을 사용합니다.

---

상세 정보int32_t보다는int_fast32_t: 레어 머신에서는INT_FAST32_MIN-2,194,483,647 이며 -2,194,483,648 이 될 수 없습니다.큰 점:(u)intN_t타입이 엄격하게 지정되어 있어, 휴대 가능한 코드로 연결됩니다.

왜 많은 사람들이uint32_t보다는uint32_fast_t?

바보 같은 대답:

• 표준 유형이 없습니다.uint32_fast_t올바른 철자는 다음과 같습니다.uint_fast32_t.

실용적인 답변:

• 실제로 많은 사람들이uint32_t또는int32_t정확한 시멘틱스에서는 부호 없는 랩 어라운드 산술로 정확히 32비트(uint32_t) 또는 2의 보완 표현(int32_t).xxx_fast32_t타입이 크기 때문에 바이너리 파일에 저장하거나, 패킹된 어레이 및 구조에서 사용하거나, 네트워크를 통해 전송하기에 적합하지 않을 수 있습니다.게다가, 그들은 심지어 더 빠르지 않을 수도 있다.

실용적인 답변:

• 많은 사람들이 단지 (또는 전혀 개의치 않는) 것에 대해 알지 못한다.uint_fast32_t코멘트 및 답변에서 설명된 바와 같이 아마 쉽게 가정할 수 있습니다.unsigned int현재 많은 아키텍처가 여전히 16비트를 가지고 있지만 동일한 의미론을 가지고 있다.int및 일부 희귀 박물관 샘플은 32보다 작은 다른 이상한 크기를 가지고 있습니다.

UX 답변:

• 보다 빠를 수도 있지만uint32_t,uint_fast32_t사용 속도가 느립니다.입력하는 데 시간이 오래 걸립니다.특히 C 매뉴얼에서 철자법과 의미론을 검색하기 위한 어카운팅이 중요합니다.- )

우아함이 중요합니다(명백한 의견 기반):

• uint32_t많은 프로그래머가 자신의 것을 정의하는 것을 선호할 정도로 나빠 보인다.u32또는uint32입력...이런 관점에서 보면uint_fast32_t수리할 수 없을 정도로 서툴러 보여요친구들과 함께 벤치에 앉아있는 것도 놀랄 일이 아니다.uint_least32_t뭐 그런 거.

정확성과 코딩의 용이성의 관점에서,uint32_t보다 많은 이점이 있다uint_fast32_t특히 위의 많은 사용자들이 지적한 바와 같이, 보다 정확하게 정의된 크기와 산술적 의미론 때문이다.

아마 놓쳤을지도 모르는 것은, 의 장점이라고 생각되는 것은uint_fast32_t- 더 빨라질 수 있지만, 의미 있는 방법으로 실현되지 않을 뿐입니다.64비트 시대를 지배해 온 64비트 프로세서(대부분 x86-64 및 Aarch64)의 대부분은 32비트 아키텍처에서 발전하여 64비트 모드에서도 32비트 네이티브 동작이 고속입니다.그렇게uint_fast32_t와 똑같다uint32_t그 플랫폼들 위에.

POWER, MIPS64, SPARC와 같은 "실행" 플랫폼 중 일부는 64비트 ALU 동작만 제공하더라도 대부분의 관심 있는 32비트 동작은 64비트 레지스터에서 정상적으로 수행할 수 있습니다. 하위 32비트는 원하는 결과를 얻을 수 있습니다(또한 모든 메인스트림 플랫폼에서는 적어도 32비트를 로드/저장할 수 있습니다).왼쪽 시프트가 주요 문제이지만 대부분의 경우 컴파일러의 값/범위 추적 최적화를 통해 최적화할 수 있습니다.

가끔 약간 느린 왼쪽 시프트나 32x32->64의 곱셈이 이러한 값의 메모리 사용량을 두 배로 웃돌지는 않을 것입니다.가장 불분명한 어플리케이션만 제외하고 말입니다.

마지막으로, 트레이드오프가 주로 "메모리 사용 및 벡터화 가능성"으로 특징지어졌지만,uint32_t명령 수/속도 비교(우선)uint_fast32_t그것조차 분명치 않다.예. 일부 플랫폼에서는 일부 32비트 작업에 대한 추가 지침이 필요하지만 다음과 같은 이유로 일부 지침을 저장합니다.

• 작은 타입을 사용하면 컴파일러는 하나의 64비트 연산을 사용하여 2개의 32비트 연산을 실현함으로써 인접한 연산을 교묘하게 조합할 수 있습니다.이런 유형의 "가난한 사람의 벡터화"의 예는 드물지 않다.예를 들어 상수 생성struct two32{ uint32_t a, b; }안으로rax맘에 들다two32{1, 2} 단일로 최적화할 수 있습니다.mov rax, 0x2000164비트 버전에서는 두 가지 명령이 필요합니다.원칙적으로 인접한 연산(동일한 연산, 다른 피연산자)에서도 가능해야 하지만 실제로 본 적은 없습니다.
• 또한 메모리 사용률이 낮아지면 메모리나 캐시 설치 공간이 문제가 되지 않더라도 명령 수가 줄어들게 되는 경우가 많습니다. 이러한 유형의 구조나 어레이가 복사되기 때문에 복사되는 레지스터당 비용이 두 배로 증가합니다.

• 데이터 타입이 작을수록 데이터 구조 데이터를 효율적으로 레지스터에 저장하는 SysV ABI와 같은 보다 현대적인 호출 규칙을 이용하는 경우가 많습니다.예를 들어 레지스터에서 최대 16바이트 구조를 반환할 수 있습니다.rdx:rax. 함수 복귀 구조 4의 경우uint32_t(상수에서 초기화됨), 로 변환됩니다.

  ret_constant32():
      movabs  rax, 8589934593
      movabs  rdx, 17179869187
      ret
  

  64비트가 4개인 동일한 구조uint_fast32_t에서는, 같은 처리를 실시하려면 , 레지스터의 이동과 4개의 스토어가 필요합니다(발신자는 반환 후에 메모리로부터 값을 읽어낼 필요가 있습니다).

  ret_constant64():
      mov     rax, rdi
      mov     QWORD PTR [rdi], 1
      mov     QWORD PTR [rdi+8], 2
      mov     QWORD PTR [rdi+16], 3
      mov     QWORD PTR [rdi+24], 4
      ret
  

  마찬가지로 structure 인수를 전달할 때 32비트 값은 파라미터에 사용할 수 있는 레지스터에 약 2배 정도 밀도로 패킹되므로 레지스터 인수가 부족하여 스택으로¹ 유출될 가능성이 낮아집니다.

• 사용하시는 경우에도uint_fast32_t「속도」가 중요한 장소에서는, 고정 사이즈 타입이 필요한 장소도 자주 있습니다.예를 들어, 외부 출력, 외부 입력, ABI의 일부, 특정 레이아웃이 필요한 구조의 일부로서, 또는 스마트하게 사용할 수 있기 때문에 외부 입력의 값을 전달할 때uint32_t메모리 설치 공간을 절약하기 위해 대규모 가치 집약을 지원합니다.어떤 장소에서는uint_fast32_t및 "uint32_t" 유형은 인터페이스를 필요로 하며, (개발 복잡성 외에도), 불필요한 부호 확장자 또는 기타 크기 제한 관련 코드를 찾을 수 있습니다.컴파일러는 대부분의 경우 이 작업을 최적화하지만 크기가 다른 유형을 혼합할 때 최적화된 출력에서 이 작업을 수행하는 것이 일반적입니다.

위의 예시와 godbolt에서 플레이할 수 있습니다.

---

¹ 확실히 말하면, 구조를 레지스터에 단단히 고정하는 것이 작은 값을 얻기 위한 확실한 성공이라고는 할 수 있습니다.즉, 작은 값을 사용하려면 먼저 "추출"해야 할 수 있습니다.예를 들어, 두 구조 부재의 합계를 함께 반환하는 단순한 함수는 다음을 필요로 합니다.mov rax, rdi; shr rax, 32; add edi, eax64비트 버전에서는 각 인수가 자체 레지스터를 가져와서 하나의 레지스터만 있으면 됩니다.add또는lea그러나 "통행 중 구조물을 엄격하게 포장"하는 설계가 전체적으로 타당하다는 것을 인정한다면 값이 작을수록 이 기능을 더 활용할 수 있습니다.

몇 가지 이유가 있다.

1. 많은 사람들은 '빠른' 유형이 존재하는지 모른다.
2. 타이핑하는 것이 더 장황하다.
3. 실제 크기를 모르면 프로그램 동작을 추론하기가 어렵습니다.
4. 이 표준은 실제로 가장 빠르게 결정되지 않으며 어떤 유형이 실제로 가장 빠른지는 상황에 따라 크게 달라질 수 없습니다.
5. 플랫폼 개발자가 플랫폼을 정의할 때 이러한 유형의 크기를 고려한다는 증거는 없습니다.예를 들어 x86-64 Linux에서는 x86-64가 32비트 값에서 고속 작업을 하드웨어로 지원하지만 "고속" 유형은 모두 64비트입니다.

요약하면, 「빠른」타입은 쓸모없는 가비지입니다.특정 어플리케이션에 가장 빠른 타입을 알고 싶다면 컴파일러의 코드를 벤치마킹해야 합니다.

제가 알기로는int님은 처음에는 16비트 이상의 사이즈를 보증하는 '정수형'으로 되어 있었습니다.그때는 '합리적인' 사이즈로 간주되고 있었습니다.

32비트 플랫폼이 보편화되면서 '합리적인' 사이즈가 32비트로 변경되었다고 할 수 있습니다.

• 최신 Windows는 32비트 사용int모든 플랫폼에서 사용할 수식을 실시합니다.
• POSIX는 다음을 보증합니다.int최소 32비트입니다.
• C#, Java에는 유형이 있습니다.int32비트가 보증됩니다.

그러나 64비트 플랫폼이 표준이 되었을 때 아무도 확장하지 않았습니다.int64비트 정수가 되는 이유는 다음과 같습니다.

• 휴대성: 많은 코드가int사이즈가 32비트입니다.
• 메모리 소비량: 1회당 메모리 사용량의 2배 증가int대부분의 경우 사용 중인 숫자는 20억보다 훨씬 작기 때문에 대부분의 경우 불합리할 수 있습니다.

이제, 왜 당신이 더 좋아하는가?uint32_t로.uint_fast32_t같은 이유로 C#과 Java는 항상 고정 크기의 정수를 사용합니다.프로그래머는 다른 유형의 가능한 크기를 고려하여 코드를 작성하지 않고 하나의 플랫폼을 위해 쓰고 해당 플랫폼에서 테스트 코드를 작성합니다.대부분의 코드는 암묵적으로 특정 크기의 데이터 유형에 의존합니다.그리고 이것이 왜uint32_t는 대부분의 경우에 더 나은 선택입니다.동작에 관한 애매모호함을 허용하지 않습니다.

더구나uint_fast32_t32비트 이상의 크기를 가진 플랫폼에서 가장 빠른 유형입니까?사실 그렇지 않아요.Windows 의 x86_64 용 GCC 에 의한 다음의 코드 컴파일러에 대해 검토해 주세요.

extern uint64_t get(void);

uint64_t sum(uint64_t value)
{
    return value + get();
}

생성된 어셈블리는 다음과 같습니다.

push   %rbx
sub    $0x20,%rsp
mov    %rcx,%rbx
callq  d <sum+0xd>
add    %rbx,%rax
add    $0x20,%rsp
pop    %rbx
retq

이제 네가 바뀌면get()에의 반환값uint_fast32_t(Windows x86_64에서는 4바이트) 다음과 같이 표시됩니다.

push   %rbx
sub    $0x20,%rsp
mov    %rcx,%rbx
callq  d <sum+0xd>
mov    %eax,%eax        ; <-- additional instruction
add    %rbx,%rax
add    $0x20,%rsp
pop    %rbx
retq

생성된 코드가 추가 코드 이외에는 거의 동일하다는 점에 유의하십시오.mov %eax,%eax32비트 값을 64비트 값으로 확장하기 위한 함수 호출 후 명령입니다.

32비트 값만 사용하는 경우에는 이러한 문제가 없지만 아마도 다음과 같은 값을 사용할 것입니다.size_tx86_64에서는 64비트입니다.Linux의 경우uint_fast32_t8바이트이기 때문에 상황은 다릅니다.

많은 프로그래머가 사용하고 있다int(예를 들어 [-32,32]의 범위 내에서) 작은 값을 반환할 필요가 있는 경우.만약 그렇다면 이것은 완벽하게 작동할 것이다.int플랫폼 네이티브 정수 사이즈가 됩니다만, 64비트 플랫폼에는 없기 때문에 플랫폼 네이티브타입과 일치하는 다른 타입을 선택하는 것이 좋습니다(크기가 작은 다른 정수에서 자주 사용되는 경우는 제외).

기본적으로, 기준에 상관없이,uint_fast32_t일부 구현에서는 문제가 발생합니다.일부 위치에서 생성되는 추가 명령이 필요한 경우, 고유한 "원본" 정수 유형을 정의해야 합니다.또는 를 사용할 수 있습니다.size_t보통 일치하기 때문에 이 목적을 위해native크기(8086과 같은 오래되고 잘 알려지지 않은 플랫폼은 포함하지 않습니다.Windows, Linux 등을 실행할 수 있는 플랫폼만 포함합니다).

---

또 다른 징후는int원래 원어민 정수형이어야 했던 것은 "승격 규칙"입니다.대부분의 CPU는 네이티브에서만 작업을 실행할 수 있기 때문에 32비트 CPU는 보통 32비트의 덧셈, 뺄셈 등을 실행할 수 있습니다(여기서는 인텔 CPU는 예외입니다).다른 크기의 정수 유형은 로드 및 저장 명령을 통해서만 지원됩니다.예를 들어 8비트 값은 적절한 "load 8-bit signed" 또는 "load 8-bit unsigned" 명령을 사용하여 로드해야 하며 로드 후에는 값이 32비트로 확장됩니다.정수 승격 규칙이 없으면 C 컴파일러는 네이티브타입보다 작은 타입을 사용하는 식에 코드를 추가해야 합니다.64비트 아키텍처에서는 컴파일러가 추가 명령을 실행해야 하는 경우가 있기 때문에 아쉽게도 이것은 더 이상 유지되지 않습니다.

대부분의 경우 알고리즘이 데이터 배열에서 작동할 때 성능을 향상시키는 가장 좋은 방법은 캐시 누락 횟수를 최소화하는 것입니다.각 요소가 작을수록 캐시에 들어갈 수 있는 요소가 많아집니다.이것이 64비트 머신에서 32비트 포인터를 사용하기 위해 여전히 많은 코드가 작성되는 이유입니다.그것들은 4GiB에 가까운 데이터를 필요로 하지 않지만 모든 포인터와 오프셋을 만들기 위해서는 4바이트가 아닌 8바이트가 필요합니다.

또, IPv4 주소 등, 정확하게 32비트를 필요로 하도록 지정된 ABI나 프로토콜도 있습니다.그렇구나uint32_t즉, CPU의 효율 여부에 관계없이 정확히 32비트를 사용합니다.이들은 과거 다음과 같이 선언되었다.long또는unsigned long64비트 이행 중에 많은 문제를 일으켰습니다.최대 2µ²-1의 숫자를 포함하는 부호 없는 유형이 필요한 경우, 이것이 바로 다음과 같은 정의입니다.unsigned long첫 번째 C 표준이 나온 이후로요.그러나 실제로는 충분히 오래된 코드는long포인터, 파일 오프셋 또는 타임스탬프를 저장할 수 있으며, 컴파일러가 반드시 만들 수 있는 것은 아닙니다.long와 같은int_fast32_t너무 많이 깨지지 않고요.

이론적으로, 프로그램이 사용하는 것이 더 미래에 대비될 것이다.uint_least32_t로딩할 수도 있습니다.uint_least32_t요소에서 a로uint_fast32_t계산 변수입니다.도입이 필요 없는 경우uint32_ttype은 표준 준수를 선언할 수도 있습니다. (기존의 많은 프로그램을 컴파일 할 수 없습니다.)실제로 아키텍처는 더 이상 존재하지 않습니다.int,uint32_t,그리고.uint_least32_t현재 퍼포먼스에 있어서도 동일하지 않고 장점도 없습니다.uint_fast32_t그럼 왜 일을 너무 복잡하게 만들죠?

하지만 그 이유를 보세요32_t이미 존재해야 할 유형입니다.long그리고 그 가정들은 전에도 우리 얼굴에 폭발한 적이 있다는 것을 알게 될 것이다.언젠가는 정확한 폭의 32비트 계산이 네이티브 워드 크기보다 느린 기계에서 코드가 실행되게 될 수 있습니다.또한 사용하는 것이 더 좋았을 수도 있습니다.uint_least32_t스토리지 및uint_fast32_t열심히 계산하기 위해서요.아니면 다리를 건널 때 간단한 걸 원한다면unsigned long.

직접 대답하려면:진짜 이유는uint32_t에 사용되다uint_fast32_t또는uint_least32_t간단히 말하면 타이핑이 쉽고, 게다가 보다 짧고, 보다 읽기 쉽다는 것입니다.어떤 타입으로 구조물을 만들고 어떤 타입은uint_fast32_t혹은 비슷한 경우, 그것들을 잘 맞추기가 어렵습니다.int또는bool또는 상당히 짧은 C의 다른 유형(대소문자:char대.character물론 하드 데이터로 백업을 할 수는 없지만, 다른 답변도 그 이유를 추측할 수 있을 뿐입니다.

기술적인 이유로 선호되는 경우uint32_t어떤 것도 없다고 생각합니다.정확한 32비트 부호 없는 int가 절대적으로 필요한 경우, 이 타입만이 표준화된 선택입니다.그 외의 거의 모든 경우, 기술적으로 다른 변종이 선호됩니다. 구체적으로는,uint_fast32_t속도가 걱정된다면uint_least32_t저장공간이 걱정되는 경우.사용.uint32_t두 경우 모두 유형이 존재할 필요가 없기 때문에 컴파일할 수 없는 위험이 있습니다.

실제로,uint32_t및 관련 타입은 현재 모든 플랫폼에 존재하지만 일부 매우 드문 DSP 또는 조크 실장은 예외입니다.따라서 정확한 타입을 사용해도 실제 위험은 거의 없습니다.마찬가지로 고정폭 타입에서는 속도 위반이 발생할 수 있지만 (현대 CPU에서는) 더 이상 장애가 되지 않습니다.

그렇기 때문에 대부분의 경우 프로그래머의 게으름 때문에 키가 작은 쪽이 유리하다고 생각합니다.

한 가지 이유는unsigned int는, 특별한 typedef나 무언가를 포함할 필요 없이, 이미 「확장」되어 있습니다.그러니 빨리 필요하시면 기본을 사용하시면 됩니다.int또는unsigned int유형.
이 표준은 가장 빠르다는 것을 명시적으로 보장하지는 않지만, 3.9.1에서 "플레인 ints have the natural size of execution environment"라고 언급함으로써 간접적으로 보증합니다.바꿔 말하면int(또는 서명되지 않은 부품)이 프로세서가 가장 사용하기 쉬운 부분입니다.

물론 어떤 사이즈인지 모르실 겁니다.unsigned int지도 모른다.적어도 다음 크기만큼 크다는 것만 알 수 있습니다.short(기억이 나는 것 같다)short최소 16비트여야 합니다만, 지금은 표준에서는 찾을 수 없습니다!)보통 단순 4바이트이지만 이론상으로는 더 크거나 극단적인 경우에는 더 작을 수 있습니다. 개인적으로 이런 아키텍처는 본 적이 없지만 1980년대 8비트 컴퓨터에서도 본 적이 없습니다. 어쩌면 마이크로컨트롤러들일지도 몰라 제가 치매에 걸려서int그 당시에는 16비트였습니다.)

C++ 규격에서는, 이 코드의 내용을 지정할 필요가 없습니다.<cstdint>타입은 또는 그 보증 대상이며, 단지 「C와 같다」라고 기재되어 있을 뿐입니다.

uint32_tC 규격에 따라 정확하게 32비트를 얻을 수 있습니다.다른 것도 없고, 패딩 비트도 없고때로는 이것이 바로 당신이 필요로 하는 것이기 때문에 매우 가치가 있습니다.

uint_least32_t는 크기가 무엇이든 32비트보다 작을 수 없음을 보증합니다(단, 더 클 수 있습니다).때때로, 하지만 정확한 witth나 "Don't care"보다 훨씬 드물게, 이것이 당신이 원하는 것입니다.

마지막으로...uint_fast32_t제 생각에는 불필요한 것 같습니다만, 문서 작성의 목적을 제외하곤요.C 표준은 "일반적으로 가장 빠른 정수 유형을 지정한다"(일반적으로 "라는 단어에 주목한다)고 명시하고 있으며, 모든 목적을 위해 가장 빠를 필요는 없다고 명시적으로 언급하고 있습니다.바꿔 말하면uint_fast32_t와 거의 같다uint_least32_t일반적으로 가장 빠른 속도이지만 보증은 제공되지 않습니다(그러나 어느 쪽이든 보증은 없습니다.

대부분의 경우 정확한 크기는 신경 쓰지 않거나 32비트(또는 64비트, 때로는 16비트)를 원하기 때문에 "상관없음"을 사용할 수 있습니다.unsigned int타입은 어쨌든 가장 빠릅니다.이것이 그 이유를 설명해 줍니다.uint_fast32_t잘 쓰이지 않습니다.

라는 증거는 본 적이 없다uint32_t범위로 사용되다대신, 내가 본 대부분의 시간은uint32_t다양한 알고리즘에서 정확히 4옥텟의 데이터를 보관하고 랩어라운드 및 시프트 시멘틱스를 보증합니다.

다른 이유들도 있습니다.uint32_t대신uint_fast32_t: 많은 경우 안정적인 ABI를 제공합니다.또, 메모리 사용량을 정확하게 알 수 있습니다.이것은 속도 상승이 어떤 것이든 상쇄시킨다.uint_fast32_t그 타입이 의 타입과 구별되는 경우는,uint32_t.

65536보다 작은 값에는 이미 편리한 유형이 있습니다.unsigned int(unsigned short적어도 그 범위도 필요합니다만,unsigned int네이티브 워드사이즈입니다). 4294967296보다 작은 값에는 다른 콜이 있습니다.unsigned long.

---

그리고 마지막으로, 사람들은 그것을 사용하지 않는다.uint_fast32_t타이핑이 짜증날 정도로 길고 오타가 생기기 쉽기 때문입니다.d

실제적인 목적을 위해,uint_fast32_t전혀 쓸모가 없어요.가장 광범위한 플랫폼(x86_64)에서 잘못 정의되어 있으며, 매우 낮은 품질의 컴파일러를 사용하지 않는 한 어떤 이점도 얻을 수 없습니다.개념적으로 데이터 구조/어레이에 고속 타입을 사용하는 것은 의미가 없습니다.운용 효율이 높은 타입에서 절약되는 비용(캐시 누락 등)은 작업 데이터 세트의 크기를 늘리는 데 드는 비용보다 작아집니다.또한 개별 로컬 변수(루프 카운터, 템프 등)에 대해 비장난감 컴파일러는 일반적으로 생성된 코드의 더 큰 유형으로 동작하며 정확성을 위해 필요한 경우에만 공칭 크기로 잘라낼 수 있습니다(서명된 유형에서는 절대 필요하지 않습니다).

이론적으로 유용한 한 가지 변종은uint_least32_t32비트 값을 저장할 수 있지만 정확한 사이즈의 32비트 타입이 없는 머신으로 이식할 필요가 있는 경우.하지만 실질적으로, 말하자면, 그건 당신이 걱정할 필요가 없는 것입니다.

언급URL : https://stackoverflow.com/questions/46959685/why-would-uint32-t-be-preferred-rather-than-uint-fast32-t