2015-01-27 13 views
6

z normy ISO/IEC 9899:Do czego przydatne są liczby całkowite o minimalnej szerokości?

7.18.1.2 minimalnej szerokości liczby całkowite

1 Nazwa typedef int_leastN_t oznacza podpisaną typu całkowitą o szerokości co najmniej N, tak że nie jest liczba całkowita ze znakiem typ o mniejszym rozmiarze ma co najmniej określoną szerokość. Tak więc int_least32_t oznacza liczbę całkowitą ze znakiem, której szerokość wynosi co najmniej 32 bity.

Dlaczego powinienem używać tego typu?

Kiedy podejmuję decyzję, jaki typ powinienem wziąć dla zmiennej, której potrzebuję, to pytam siebie: "Jaka będzie największa wartość, jaką może kiedykolwiek mieć?"

Więc mam zamiar znaleźć odpowiedź, sprawdzić, co jest najniższym 2 n, która jest większa niż i wziąć dokładny typ całkowity.

Tak więc w tym przypadku mógłbym użyć również typu całkowitej o minimalnej szerokości. Ale dlaczego? Jak już wiem: nigdy nie będzie to większa wartość. Dlaczego więc wziąć coś, co może czasem pokryć jeszcze więcej, gdy potrzebuję?

wszystkich innych przypadkach mogę Imagin gdzie nawet nieważne jak np:

„Mam typ, który będzie przynajmniej wielkość ...” - The implmentation nie może wiedzieć, co będzie największym (na przykład) dane wejściowe użytkownika, które kiedykolwiek otrzymam, więc dostosowanie typu podczas kompilacji nie pomoże.

"Mam zmienną, w której nie mogę określić, jaki rozmiar wartości będzie przechowywany w czasie wykonywania."

- Jak kompilator może wiedzieć podczas kompilacji? -> Nie może znaleźć również dopasowanego rozmiaru bajtu.

Więc jakie jest użycie tych typów?

Odpowiedz

5

Ponieważ Twój kompilator wie najlepiej, co jest dla Ciebie dobre. Na przykład w niektórych architekturach procesorów obliczenia obejmujące typy 8 lub 16 bitowe mogą być znacznie wolniejsze niż obliczenia wykonywane w 32 bitach ze względu na dodatkowe instrukcje dotyczące maskowania argumentów i wyników w celu dopasowania ich szerokości.

Na przykład implementacja C na Cray Unicos ma tylko 8-bitowy znak char, wszystko inne (krótkie, długie, długie i długie) ma wartość 64-bitową. Jeśli wymusisz, aby typ był int16_t lub int32_t, wydajność może drastycznie zmaleć z powodu wąskich sklepów wymagających maskowania, oringowania i tworzenia. Zastosowanie int_least32_t pozwoliłoby kompilatorowi na użycie natywnego 64-bitowego typu.

+0

Awans do edycji. Nie zdawałem sobie sprawy, że typy "intN_t" mogą być rzeczywiście emulowane w oprogramowaniu, jeśli nie są dostępne w inny sposób. – user694733

+4

@ Jen i dlaczego powinienem użyć int_least32_t zamiast int_fast32_t w tym celu? – dhein

+0

@Zaibis Ponieważ priorytetem jest oszczędność przestrzeni zamiast prędkości. – Jens

5

Po co więc wziąć coś, co może czasem pokryć jeszcze więcej, czego potrzebuję?

Ponieważ nie zawsze może być potrzebny odpowiedni rozmiar. Na przykład w systemie, w którym CHAR_BIT > 8, int8_t jest niedostępny, ale jest int_least8_t.

Pomysł nie polega na tym, że kompilator zgadnie, ile bitów potrzebujesz. Pomysł polega na tym, że kompilator zawsze będzie posiadał dostępny typ, który spełni wymagania dotyczące rozmiaru, nawet jeśli nie może zaoferować dokładnego rozmiaru.

+0

Czy byłby w tym przypadku na przykład uint10_t, jeśli charbit miałby 10? Czyli dla celów przenośnościowych nie potrzebuję sprawdzać wartości CHAR_BIT przez siebie i czy nie muszę odpowiadać iofdefs? i czy istnieją systemy w praktyce, gdzie CHAR_BIT ma wartość> 8? – dhein

+3

Wszystkie typy 'intN_t' są opcjonalne w systemach uzupełniających non 2. Więc nie są one użyteczne dla przenośnego kodu. Ale "uint10_t" jest dozwolone przez standard (N1570: 7.20.1.1.2). Uważam, że istnieją systemy, w których CHAR_BIT> 8, ale nie pamiętam, jak istotne są one dzisiaj. – user694733

+1

Obecnie systemy z CHAR_BIT> 8 to głównie procesory DSP http://stackoverflow.com/questions/2098149/what-platforms-have-something-other-than-8-bit-char?lq=1 –

Powiązane problemy