인트형이 4바이트던 시절도 있었나여?

[익명(175.223)]

아는형 좆소부장님이 인트는 4바이트라고 우기고있는데

그형이 8바이트라고 싸우다 퇴사했데서요

근데이거 프로세서마다 다른거잖음?

[관노(223.33)]

니네 형도 옳고 부장도 옳다, 근데 둘 다 ㅂㅅ이다.

[익명(115.40)]

.... 둘다 힘 넘치네

[rapzzard(rapzzard)]

나중에 알고 나면 평생 이불킥 감이넹-_-;; 두분 다 자기계발은 하나도 안하시는 모양;; 그 얘기 나오는 걸로 보면 C/C++로 밥벌어 먹고 사시는 모양인데;; LP64/ILP64/기타 등등은 하도 오래된 떡밥이라 이제 쉰내가 남;;

[codesafer(codesafer)]

int가 무슨 프로세서를 따라가 컴파일러를 따라가지 멍청

[익명(198.7)]

결과적으로 그 회사 짤린게 잘된거 sizeof(int)도 할지 모르는 회사는 비전없음

[rapzzard(rapzzard)]

@ㅇㅇ : 부장도 문제지만 형도 같이 문제인디? ㅎㅎㅎ 회사가 코딩함? 엔지니어가 코딩하지

[안티푸라면(pparkppark)]

2바이트인 시기도 있었건만.. 갈!!

[ㅅㅅㅅ(125.128)]

우선 코세 성님 말씀대로 int 형의 크기는 당연히 컴파일러 따라 가는 게 맞음. C언어 표준에서는 자료형의 크기에 대해서 최소치와 상대적인 대소 관계만 정의해 놨을 뿐 정확하게 나온 건 sizeof(char) == 1 뿐이니깐(이것도 sizeof 연산자의 결과에 대해 정의한 거지 char 형 자체의 크기는 아님). 하지만 컴파일러가 자료형의 크기를 정할 때 출력물의 타깃이 되는 시스템의 환경(프로세서, OS 등)을 고려해서 결정함. 그래서 int 형은 프로세서 따라간다고 하는 얘기가 완전히 틀린 얘기는 아님. 일단 역사적으로 C언어의 int 형이 B언어에서는 word 형이었는데 word는 CPU가 한번에 처리할 수 있는 정수의 크기를 말하는 거니깐. 역사적인 의미로 본다면 int 형은 프로세서의 비트 수에

[ㅅㅅㅅ(125.128)]

따라 가는 게 맞는데 컴파일러를 만들 때 타깃의 OS도 고려를 하지 않을 수가 없는데 OS의 system call 등과 완활히 상호작용하기 위해서는 타입을 어느 정도 맞춰줄 필요가 있음. 이런 복잡한 뒷사정 때문에 64비트 시스템에서 자료형 크기를 결정한 방법에 따라 LLP64, LP64, ILP64, SILP64 같이 데이터 모델들이 생겨 났을 뿐임. 일단 대세를 말하자면 64비트 시스템에서도 대부분은 int 형이 32비트 크기를 갖고 일부 시스템에서만 64비트의 크기를 가짐.

[ㅅㅅㅅ(125.128)]

개인적으로 이상적인 모델은 64비트 시스템에서 short = 16bit, long = 32bit, long long = 64bit, int = 64bit (int = word size, short/long/long long = 사이즈가 정해진 정수)로 모델링하는 게 이상적이라고 봄. int 형의 역사적인 의미에도 맞고. long과 long long이 둘 다 64비트인 ILP64, SILP64 같은 모델링은 long long이 이름에서도 알 수 있듯이 long의 두 배 크기라는 의미를 담고 있는데 그걸 져 버린 거라 자료형의 원래 의도에 반하는 것이라 봄.

[ㅅㅅㅅ(125.128)]

그리고 실무에서 int 형의 크기가 중요하면 sizeof(int) 해도 되고 limits.h 헤더의 상수를 참조해도 되는데 그냥 크기를 하나로 단정짓고 짜는 건 병슨 짓임.