Jedynym powodem, aby używać uint8_t zamiast unsigned char (poza preferencjami estetycznymi) jest to, że chcesz udokumentować, że twój program wymaga char Dokładnie 8 bitów. uint8_t Istnieje wtedy i tylko wtedy, gdy CHAR_BIT==8, zgodnie z wymaganiami normy C.

Reszta typów intX_t i uintX_t jest przydatna w następujących sytuacjach:

• Odczyt / Zapis dysku / sieci (ale wtedy musisz również użyć funkcji konwersji endian)
• gdy chcesz unsigned wraparound zachowanie przy dokładnym odcięciu (ale można to zrobić bardziej przenośnie za pomocą operatora &).
• gdy kontrolujesz dokładny układ struktury, ponieważ musisz upewnić się, że nie istnieje wypełnienie (np. dla memcmp lub celów hashujących).

Z drugiej strony uint_least8_t, itd. typy są przydatne wszędzie tam, gdzie chcesz uniknąć używania zbyt dużych lub powolnych typów, ale musisz mieć pewność, że możesz przechowywać wartości o określonej wielkości. Na przykład, gdy long long ma co najmniej 64 bity, to na niektórych maszynach może być 128-bitowy, a używanie go, gdy potrzebujesz tylko typu, który może przechowywać numery 64-bitowe, byłoby bardzo marnotrawne na takich maszynach. int_least64_t rozwiązuje problem.

Unikałbym całkowicie używania typów [u]int_fastX_t, ponieważ czasami zmieniały się na danej maszynie (łamiąc ABI) i ponieważ definicje są zwykle błędne. Na przykład, na x86_64, 64-bitowy Typ integer jest uważany za "szybki" Dla wartości 16-, 32-i 64-bitowych, ale podczas dodawania, odejmowanie i mnożenie to dokładnie ta sama prędkość niezależnie od tego, czy używasz wartości 32-bitowych, czy 64-bitowych, dzielenie jest prawie na pewno wolniejsze przy większych niż konieczne typach, a nawet jeśli były one taką samą prędkością, używasz dwukrotnie większej pamięci bez żadnych korzyści.

Na koniec, zauważ, że argumenty, które pojawiły się w niektórych odpowiedziach na temat nieefektywności użycia int32_t dla licznika, gdy nie jest to natywna wielkość całkowita, są technicznie w większości poprawne, ale nie ma znaczenia poprawność kodu. Chyba, że jesteś zliczając niewielką liczbę rzeczy, na których maksymalna liczba jest pod twoją kontrolą, lub jakąś zewnętrzną (nie znajdującą się w pamięci programu) rzecz, w której liczba może być astronomiczna, prawidłowym typem dla liczenia jest prawie zawsze size_t. Dlatego wszystkie standardowe funkcje C używają size_t do zliczania. Nie myśl o używaniu niczego innego, chyba że masz bardzo dobry powód.

Cons

Główny powód, dla którego język C nie określa wielkości int LUB long, itd. jest dla wydajności obliczeniowej. Każda architektura ma naturalny, najbardziej wydajny rozmiar, a projektanci specjalnie upoważnili i zamierzali implementatora kompilatora do korzystania z naturalnych danych natywnych dla szybkości i wydajności rozmiaru kodu.

W minionych latach komunikacja z innymi maszynami nie była głównym problemem-większość programów była lokalna dla maszyny-więc przewidywalność rozmiar każdego typu danych był niewielki.

Naleganie, aby konkretna Architektura używała określonego rozmiaru int do liczenia Z jest naprawdę złym pomysłem , chociaż wydaje się, że ułatwia to inne rzeczy.

W pewnym sensie, dzięki XML i jego braciom, Rozmiar typu danych ponownie nie jest już problemem. Przesyłanie specyficznych dla maszyny struktur binarnych z maszyny do maszyny jest znowu wyjątkiem, a nie regułą.

Używam typów stdint tylko z jednego powodu, gdy dane, które przechowuję w pamięci, trafiają na dysk/sieć/deskryptor w postaci binarnej. Musisz tylko walczyć z problemem little-endian/big-endian, ale jest to stosunkowo łatwe do przezwyciężenia.

Oczywistym powodem nie do używania stdint jest to, że kod jest niezależny od rozmiaru, w matematyce wszystko, co działa nad racjonalnymi liczbami całkowitymi. Wygenerowałoby to brzydkie duplikaty kodu, gdybyś podał uint*_t wersję, powiedzmy, qsort() dla każde rozszerzenie *.

Używam w tym przypadku własnych typów, wywodzących się z size_t, Gdy jestem leniwy, lub największej obsługiwanej niepodpisanej liczby całkowitej na platformie, gdy nie jestem.

Edit, bo natknąłem się na ten problem wcześniej:
Myślę, że warto zauważyć, że przynajmniejuint8_t, uint32_t i uint64_t są zepsute w Solarisie 2.5.1. Tak więc dla maksymalnej przenośności nadal sugeruję unikanie stdint.h (przynajmniej przez najbliższe kilka lat).