uint8_t vs unsigned char

Jakie są zalety korzystania z uint8_tciągu unsigned charw C?

Wiem, że w prawie każdym systemie uint8_tjest po prostu typedef unsigned char, więc po co go używać?

Dokumentuje to twoją intencję - będziesz przechowywać małe liczby zamiast postaci.

Wygląda też ładniej, jeśli używasz innych typów czcionek, takich jak uint16_tlub int32_t.

Żeby być pedantycznym, niektóre systemy mogą nie mieć typu 8-bitowego. Według Wikipedii :

Implementacja jest wymagana do zdefiniowania typów liczb całkowitych o dokładnej szerokości dla N = 8, 16, 32 lub 64 tylko wtedy, gdy ma dowolny typ spełniający wymagania. Nie jest wymagane ich zdefiniowanie dla żadnego innego N, nawet jeśli obsługuje odpowiednie typy.

Nie uint8_tma gwarancji, że będzie istnieć, chociaż będzie to miało miejsce na wszystkich platformach, na których 8 bitów = 1 bajt. Niektóre platformy wbudowane mogą się różnić, ale staje się to bardzo rzadkie. Niektóre systemy mogą definiować chartypy na 16 bitów, w takim przypadku prawdopodobnie nie będzie żadnego typu 8-bitowego.

Poza tym (mniejszym) problemem, odpowiedź @ Mark Ransom jest moim zdaniem najlepsza. Użyj tego, który najlepiej pokazuje, do czego używasz danych.

Zakładam również, że miałeś na myśli uint8_t(standardowy typedef z C99 podany w stdint.hnagłówku), a nie uint_8(nie jest częścią żadnego standardu).

Chodzi o to, aby napisać kod niezależny od implementacji. unsigned charnie jest gwarantowanym typem 8-bitowym. uint8_tjest (jeśli dostępne).

Jak powiedziałeś, „ prawie każdy system”.

charjest prawdopodobnie jedną z mniej prawdopodobnych zmian, ale kiedy zaczniesz używać uint16_ti znajomych, uint8_tlepiej używasz mieszania, a nawet może być częścią standardu kodowania.

Z mojego doświadczenia wynika, że ​​istnieją dwa miejsca, w których chcemy używać uint8_t w celu oznaczenia 8 bitów (i uint16_t itp.) I gdzie możemy mieć pola mniejsze niż 8 bitów. Oba miejsca mają znaczenie dla przestrzeni i często musimy spojrzeć na surowy zrzut danych podczas debugowania i musimy być w stanie szybko określić, co to reprezentuje.

Pierwszy dotyczy protokołów RF, szczególnie w systemach wąskopasmowych. W tym środowisku może być konieczne spakowanie jak największej ilości informacji w jedną wiadomość. Drugi dotyczy pamięci flash, w której możemy mieć bardzo ograniczoną przestrzeń (na przykład w systemach wbudowanych). W obu przypadkach możemy użyć struktury danych spakowanych, w których kompilator zajmie się dla nas pakowaniem i rozpakowywaniem:

#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()

Wybór metody zależy od kompilatora. Konieczne może być także wsparcie kilku różnych kompilatorów z tymi samymi plikami nagłówkowymi. Dzieje się tak w systemach wbudowanych, w których urządzenia i serwery mogą być zupełnie inne - na przykład możesz mieć urządzenie ARM, które komunikuje się z serwerem Linux x86.

Istnieje kilka zastrzeżeń dotyczących używania upakowanych struktur. Największym problemem jest to, że musisz unikać dereferencji adresu członka. W systemach ze słowami wyrównanymi mutibajtami może to spowodować niepoprawny wyjątek i zrzut rdzeniowy.

Niektórzy ludzie martwią się również wydajnością i twierdzą, że użycie tych spakowanych struktur spowolni twój system. Prawdą jest, że za kulisami kompilator dodaje kod, aby uzyskać dostęp do nieprzystosowanych elementów danych. Możesz to zobaczyć patrząc na kod asemblera w twoim IDE.

Ponieważ jednak upakowane struktury są najbardziej przydatne do komunikacji i przechowywania danych, dane można wyodrębnić do niepakowanej reprezentacji podczas pracy z nimi w pamięci. Zwykle i tak nie musimy pracować z całym pakietem danych w pamięci.

Oto kilka istotnych dyskusji:

pragma pack (1) ani __attribute__ ((wyrównany (1))) działa

Czy pakiet gcc __attribute __ ((pack)) / #pragma jest niebezpieczny?

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

Jest mało Z punktu widzenia przenośności charnie może być mniejszy niż 8 bitów i nic nie może być mniejsze niż char, więc jeśli dana implementacja C ma 8-bitową liczbę całkowitą bez znaku, będzie char. Alternatywnie może nie mieć go wcale, w którym to momencie jakiekolwiek typedefsztuczki są dyskusyjne.

Można go użyć do lepszego udokumentowania kodu w tym sensie, że jest jasne, że potrzebujesz tam 8-bitowych bajtów i nic więcej. Ale w praktyce jest to rozsądne oczekiwanie praktycznie już wszędzie (istnieją platformy DSP, na których to nieprawda, ale szanse na uruchomienie tam kodu są niewielkie, a równie dobrze możesz popełnić błąd, używając statycznego potwierdzenia na górze programu na taka platforma).

Jest to naprawdę ważne na przykład podczas pisania analizatora sieci. nagłówki pakietów są definiowane przez specyfikację protokołu, a nie sposób działania kompilatora C dla konkretnej platformy.

Niemal na każdym systemie poznałem uint8_t == unsigned char, ale nie gwarantuje tego standard C. Jeśli próbujesz napisać przenośny kod i ma on znaczenie, dokładnie jaki jest rozmiar pamięci, użyj uint8_t. W przeciwnym razie użyj znaku bez znaku.