size_t

size_t can store the maximum size of a theoretically possible object of any type

• unsigned.
  • 가장 골치아픈 변수 버그들 중 하나인 unsigned와 signed 변수의 혼합 계산 오류 때문에 쓰기가 꺼려진다. 정말 잘 제어해서 쓰거나 다른 연산이 불필요한 for 루프 카운터에만 쓰는 식이 아니라면 이 문제가 언제 터질지 모른다. 오버플로우나 막장 연산자 혼합문제와 비슷한 양상의 계산 버그가 생길 수 있다.
  • 굳이 한 비트 더 써서 최대치를 늘릴 필요가 별로 없다. 32비트만 해도 최대치가 원체 높아서 넘어갈 가능성이 거의 없는데다 혹시나 최대치를 넘길 경우 signed는 음수값 오류 체크라도 가능하지 unsigned는... 답이 없다.
  • 위 정보는 잘못된 정보이다. signed 자료형의 overflow는 undefined-behavior이다. [1]

• Visual Studio는 size_t를 비표준으로 구현해두었다. 그래서 특히 구버전 컴파일러는 이 자료형을 이상하게 취급한다. 매크로 문제도 있다. 간혹 이걸 '구조체 비트필드' 로 구현해놓은 충공깽인 경우도 있다. 이러면 통상의 변수처럼 쓸 수가 없어진다.
• 추가 헤더 #include <cstddef>, <stddef.h> 가 필요하다. 표준 라이브러리 구현에 따라 안 넣어도 자체포함하는 경우도 있다.
• 코딩 일관성을 해친다.
  • 타겟 플랫폼에 따라 가변적으로 최대치가 변해버리기 때문에 제어하기 힘들며 [2]
  • 역방향 루프 같은 경우에는 쓰려면 일부러 복잡하게 바꿔야 한다. 그냥 int 같은 걸 쓰면 알고리즘이 좀 달라도 비슷하게 쓸 수 있는 문장을 size_t를 쓰는 순간 마이너스를 고려해서 두 가지로 써야 한다.
  • 쓰는 사람에 따라 size_t, std::size_t 두 종류의 문법이 있는 것도 문제다. 간혹 ::size_t 로 쓰는 사람도 있다. 표준이 왜 이래
  • std::size_t는 구버전 코드에서는 잘 동작하지도 않는다. 특히 C에서는 잘 안 먹힌다.
• 변수 용량 최대치라는 점은 지금 현재로써는 int를 쓰면 가변적으로 거의 잘 맞춰주며 예전처럼 메모리 공간에 목숨거는 환경이 아니라는 점도 크다. 임베디드 개발이 아니라면야
• size_t, 특히 std::size_t는 단어도 훨씬 긴데다 치기 껄끄러운 ::과 _까지 있다. 타자 편의성에서 압도적으로 밀린다.