때때로, 누군가 SO char(일명 ‘바이트’)가 반드시 8 비트는 아니라고 지적합니다 .
8 비트 char는 거의 보편적 인 것 같습니다 . 주류 플랫폼의 char경우 시장에서 생존 가능성을 보장하기 위해 8 비트가 필요하다고 생각했을 것 입니다.
현재와 역사적으로 char8 비트가 아닌 어떤 플랫폼을 사용 하며 왜 “일반”8 비트와 다른가?
코드를 작성하고 플랫폼 간 지원 (예 : 범용 라이브러리)에 대해 생각할 때 8 비트가 아닌 플랫폼에 어떤 종류의 고려가 필요 char합니까?
과거 char에는 16 비트 인 일부 아날로그 장치 DSP를 살펴 보았습니다 . DSP는 내가 생각하는 틈새 아키텍처입니다. (그 당시에도 수작업으로 코딩 된 어셈블러는 사용 가능한 C 컴파일러가 할 수있는 것을 쉽게 이길 수 있었으므로 해당 플랫폼에서 C에 대한 경험이 많지 않았습니다.)
답변
char또한 Texas Instruments C54x DSP에서 16 비트로, 예를 들어 OMAP2에서 나타났습니다. 16 비트와 32 비트의 다른 DSP가 있습니다 char. 24 비트 DSP에 대해 들어 본 것 같지만 무엇을 기억할 수 없으므로 상상했을 수도 있습니다.
또 다른 고려 사항은 POSIX가 위임한다는 것 CHAR_BIT == 8입니다. 따라서 POSIX를 사용하는 경우 가정 할 수 있습니다. 누군가가 나중에 POSIX를 거의 구현하기 위해 코드를 이식 해야하는 경우 사용하는 기능이 다르지만 크기가 다르기 char때문에 불행한 일입니다.
그러나 일반적으로 문제를 해결하는 것보다 문제를 해결하는 것이 거의 항상 쉽다고 생각합니다. 그냥 입력하십시오 CHAR_BIT. 정확한 8 비트 유형을 원하면을 사용하십시오 int8_t. 예상치 못한 크기를 자동으로 사용하는 대신 코드를 제공하지 않는 구현에서 코드가 시끄럽게 컴파일되지 않습니다. 적어도, 내가 그럴만 한 이유가있는 사건에 부딪쳤다면, 나는 그것을 주장 할 것입니다.
답변
코드를 작성하고 플랫폼 간 지원 (예 : 범용 라이브러리)에 대해 생각할 때 8 비트가 아닌 문자가있는 플랫폼에 어떤 종류의 고려가 필요합니까?
규칙에 따라 행동 할 때 “고려해야 할 가치”는 그리 크지 않습니다. 예를 들어 C ++에서 표준은 모든 바이트가 “최소한”8 비트를 가질 것이라고 말합니다. 코드에서 바이트가 정확히 8 비트라고 가정하면 표준을 위반하는 것입니다.
” 물론 모든 바이트에는 8 비트가 있습니다!”라는 말이 들립니다. 그러나 많은 영리한 사람들이 보장되지 않은 가정에 의존하고 모든 것이 파산되었습니다. 역사는 그러한 예들로 가득합니다.
예를 들어, 90 년대 초반의 대부분의 개발자들은 대부분의 소비자 CPU가 거의 동등한 전력을 사용하기 때문에 고정 된 횟수의주기를 갖는 특정 비 작동 CPU 타이밍 지연이 일정량의 클럭 시간을 필요로한다고 가정했습니다. 불행히도 컴퓨터는 매우 빠르게 빨라졌습니다. 아이러니하게도 시간 지연 기술을 사용하는 게임을 적절한 속도로 재생할 수 있도록 컴퓨터 속도를 낮추는 것이 목적인 “터보”버튼으로 상자가 등장했습니다.
한 의견 제시자는 표준에서 char이 최소 8 비트를 가져야한다고 말하는 곳을 물었습니다. 섹션 5.2.4.2.1에 있습니다. 이 섹션에서는 CHAR_BIT주소를 지정할 수있는 가장 작은 엔티티의 비트 수를 정의 하고 기본값은 8입니다.
그들의 구현-정의 된 값은 동일한 부호로 표시된 것 이상의 크기 (절대 값) 이상이어야한다.
따라서 8 이상의 숫자는로 구현을 대체하기에 적합합니다 CHAR_BIT.
답변
36 비트 아키텍처를 가진 머신은 9 비트 바이트를 갖습니다. Wikipedia에 따르면 36 비트 아키텍처를 가진 머신 은 다음과 같습니다.
- Digital Equipment Corporation PDP-6 / 10
- IBM 701/704/709/7090/7094
- UNIVAC 1103 / 1103A / 1105 / 1100 / 2200,
답변
내가 알고있는 몇 가지 :
- DEC PDP-10 : 가변적이지만 대부분의 경우 7 비트 문자는 36 비트 워드 당 5 개, 그렇지 않으면 9 비트 문자, 워드 당 4 개
- 제어 데이터 메인 프레임 (CDC-6400, 6500, 6600, 7600, Cyber 170, Cyber 176 등) 6 비트 문자 (60 비트 워드 당 10 개).
- 유니시스 메인 프레임 : 9 비트 / 바이트
- Windows CE :`char` 유형을 전혀 지원하지 않습니다. 대신 16 비트 wchar_t가 필요합니다.
답변
완전히 이식 가능한 코드는 없습니다. 🙂
예, 다양한 바이트 / 문자 크기가있을 수 있습니다. 예, CHAR_BIT및의 값이 매우 특이한 플랫폼에 대해 C / C ++ 구현이있을 수 있습니다 UCHAR_MAX. 예, 때로는 문자 크기에 의존하지 않는 코드를 작성할 수 있습니다.
그러나 거의 모든 실제 코드는 독립형이 아닙니다. 예를 들어 바이너리 메시지를 네트워크로 보내는 코드를 작성하고있을 수 있습니다 (프로토콜은 중요하지 않습니다). 필요한 필드가 포함 된 구조를 정의 할 수 있습니다. 직렬화 해야하는 것보다. 구조를 출력 버퍼에 바이너리로 복사하는 것은 이식성이 없습니다. 일반적으로 플랫폼의 바이트 순서 나 구조 멤버 정렬을 모르므로 구조는 데이터를 보유하지만 데이터를 직렬화하는 방법은 설명하지 않습니다. .
확인. 바이트 순서 변환을 수행 하고 버퍼를 uint32_t사용하여 구조 멤버 (예 : 또는 이와 유사한)를 이동할 수 있습니다 memcpy. 왜 memcpy? 대상 주소가 올바르게 정렬되지 않은 경우 32 비트 (16 비트, 64 비트-차이 없음)를 작성할 수없는 플랫폼이 많이 있기 때문입니다.
따라서 이미 이식성을 달성하기 위해 많은 노력을 기울였습니다.
그리고 이제 마지막 질문입니다. 버퍼가 있습니다. 데이터가 TCP / IP 네트워크로 전송됩니다. 이러한 네트워크는 8 비트 바이트를 가정합니다. 문제는 버퍼의 유형은 무엇입니까? 당신의 문자가 9 비트라면? 16 비트라면? 24? 어쩌면 각 문자는 네트워크로 전송 된 하나의 8 비트 바이트에 해당하며 8 비트 만 사용됩니까? 아니면 여러 네트워크 바이트가 24/16/9 비트 문자로 압축되어 있습니까? 그것은 하나의 질문이며, 모든 경우에 맞는 단일 답변이 있다고 믿기가 어렵습니다. 많은 것은 대상 플랫폼의 소켓 구현에 달려 있습니다.
그래서 내가 말하는 것. 일반적으로 코드는 어느 정도 쉽게 이식 할 수 있습니다 . 다른 플랫폼에서 코드를 사용할 것으로 예상되면 그렇게하는 것이 매우 중요합니다. 그러나 실제 코드는 거의 항상 다른 코드 (위의 예제에서 소켓 구현)에 의존 하기 때문에 그 측정 이상의 이식성을 향상시키는 것은 많은 노력이 필요하고 종종 거의 제공하지 않는 것 입니다. 8 비트 이외의 바이트가있는 플랫폼에서 작동하는 코드 기능의 약 90 %가 8 비트에 바인딩 된 환경을 사용하기 때문에 거의 쓸모가 없다고 확신합니다. 바이트 크기를 확인하고 컴파일 시간 어설 션을 수행하십시오. 매우 특이한 플랫폼을 위해서는 많은 것을 다시 작성해야 할 것입니다.
그러나 코드가 “독립형”이라면 왜 안될까요? 다른 바이트 크기를 허용하는 방식으로 작성할 수 있습니다.
