uint8_t vs unsigned char

uint8_t vs unsigned char

---

C에서 uint8_tover 를 사용하면 어떤 이점이 unsigned char있습니까?

거의 모든 시스템 uint8_t에서에 대한 typedef unsigned char일 뿐이 므로 왜 사용합니까?

---

그것은 당신의 의도를 문서화합니다-당신은 문자가 아닌 작은 숫자를 저장할 것입니다.

당신이 같은 다른 형식 정의를 사용하는 경우 또한 그것은 더 좋은 모습 uint16_t또는 int32_t.

---

간단한 시스템이기 때문에 일부 시스템에는 8 비트 유형이 없을 수 있습니다. Wikipedia 에 따르면 :

요구 사항을 충족하는 유형이있는 경우에만 N = 8, 16, 32 또는 64에 대해 정확한 너비 정수 유형을 정의하려면 구현이 필요합니다. 적절한 유형을 지원하더라도 다른 N에 대해서는 정의 할 필요가 없습니다.

그래서 uint8_t8 비트 = 1 바이트 모든 플랫폼는 것이지만, 존재하지 않을 수 있습니다. 일부 임베디드 플랫폼은 다를 수 있지만 매우 드물어지고 있습니다. 일부 시스템은 char유형을 16 비트로 정의 할 수 있으며,이 경우 8 비트 유형이 아닐 수 있습니다.

그 (사소한) 문제 외에 @Mark Ransom의 대답 은 내 의견으로는 최고입니다. 데이터를 가장 잘 보여주는 것을 사용하십시오.

또한 uint8_t(표준의 일부 stdint.h가 아닌) uint_8( 헤더에 제공된 C99의 표준 typedef) 를 의미한다고 가정합니다 .

---

요점은 구현 독립적 인 코드를 작성하는 것입니다. unsigned char8 비트 유형일 수는 없습니다. uint8_t입니다 (사용 가능한 경우).

---

당신이 말했듯이, " 거의 모든 시스템".

char아마 변경 가능성이 적지 만, 일단 uint16_t친구와 친구를 사용하기 시작 하면 uint8_t블렌드를 더 잘 사용 하고 코딩 표준의 일부일 수도 있습니다.

---

내 경험상 uint8_t를 사용하여 8 비트 (및 uint16_t 등)를 사용하고 8 비트보다 작은 필드를 가질 수있는 두 곳이 있습니다. 두 곳 모두 공간이 중요한 곳이므로 디버깅 할 때 데이터의 원시 덤프를 살펴보고 해당 데이터가 무엇을 나타내는 지 신속하게 결정할 수 있어야합니다.

첫 번째는 RF 프로토콜, 특히 협 대역 시스템에 있습니다. 이 환경에서는 최대한 많은 정보를 단일 메시지에 담아 야합니다. 두 번째는 공간이 매우 제한된 플래시 스토리지 (예 : 임베디드 시스템)입니다. 두 경우 모두 컴파일러가 압축 및 압축 풀기를 처리하는 압축 된 데이터 구조를 사용할 수 있습니다.

#pragma pack(1)
typedef struct {
  uint8_t    flag1:1;
  uint8_t    flag2:1;
  padding1   reserved:6;  /* not necessary but makes this struct more readable */
  uint32_t   sequence_no;
  uint8_t    data[8];
  uint32_t   crc32;
} s_mypacket __attribute__((packed));
#pragma pack()

사용하는 방법은 컴파일러에 따라 다릅니다. 동일한 헤더 파일로 여러 다른 컴파일러를 지원해야 할 수도 있습니다. 이것은 장치와 서버가 완전히 다를 수있는 임베디드 시스템에서 발생합니다. 예를 들어 x86 Linux 서버와 통신하는 ARM 장치가있을 수 있습니다.

패킹 된 구조를 사용하는 경우 몇 가지주의 사항이 있습니다. 가장 큰 문제는 회원의 주소를 역 참조하지 않아야한다는 것입니다. 뮤티 바이트로 정렬 된 단어가있는 시스템에서는 이로 인해 예외가 잘못 정렬되고 코어 덤프가 발생할 수 있습니다.

일부 사람들은 성능에 대해 걱정하고 이러한 압축 구조를 사용하면 시스템 속도가 느려질 것이라고 주장합니다. 배후에서 컴파일러가 정렬되지 않은 데이터 멤버에 액세스하는 코드를 추가하는 것은 사실입니다. IDE에서 어셈블리 코드를 보면 알 수 있습니다.

그러나 패킹 된 구조는 통신 및 데이터 저장에 가장 유용하므로 메모리에서 작업 할 때 데이터를 압축되지 않은 표현으로 추출 할 수 있습니다. 일반적으로 메모리의 전체 데이터 패킷으로 작업 할 필요는 없습니다.

다음은 관련 토론입니다.

pragma pack (1) 또는 __attribute__ ((aligned (1))) 작동

Is gcc's __attribute__((packed)) / #pragma pack unsafe?

http://solidsmoke.blogspot.ca/2010/07/woes-of-structure-packing-pragma-pack.html

---

There's little. From portability viewpoint, char cannot be smaller than 8 bits, and nothing can be smaller than char, so if a given C implementation has an unsigned 8-bit integer type, it's going to be char. Alternatively, it may not have one at all, at which point any typedef tricks are moot.

It could be used to better document your code in a sense that it's clear that you require 8-bit bytes there and nothing else. But in practice it's a reasonable expectation virtually anywhere already (there are DSP platforms on which it's not true, but chances of your code running there is slim, and you could just as well error out using a static assert at the top of your program on such a platform).

---

That is really important for example when you are writing a network analyzer. packet headers are defined by the protocol specification, not by the way a particular platform's C compiler works.

---

On almost every system I've met uint8_t == unsigned char, but this is not guaranteed by the C standard. If you are trying to write portable code and it matters exactly what size the memory is, use uint8_t. Otherwise use unsigned char.

참고URL : https://stackoverflow.com/questions/1725855/uint8-t-vs-unsigned-char