Розніца паміж uint8_t, uint_fast8_t і uint_least8_t

Стандарт C99 ўводзіць наступныя тыпы дадзеных. Дакументацыю можна знайсці тут для stdint бібліятэкі AVR.

  • uint8_t means it's an 8-bit unsigned type.
  • uint_fast8_t means it's the fastest unsigned int with at least 8 bits.
  • uint_least8_t means it's an unsigned int with at least 8 bits.

Я разумею, uint8_t і што uint_fast8_t (я не ведаю, як гэта рэалізавана ва ўзроўні рэгістраў).

1.Can вы растлумачыць, што гэта значыць "што гэта непадпісаным INT па меншай меры, 8 біт»?

2.How uint_fast8_t і uint_least8_t дапамогу павышэнне эфектыўнасці/код прасторы ў параўнанні з uint8_t ?

61
дададзена аўтар dan04, крыніца
Для вашага 1-й пытанне, які я магу сабе ўявіць, што ў той час як uint8_t гарантавана будзе 8 біт, uint_fast8_t гарантавана будзе> = 8 біт, гэтак жа, як у непадпісаныя сімвал .
дададзена аўтар jacob, крыніца
Адным з фактараў з'яўляецца тое, што uint8_t не існуе ў сістэмах, якія не маюць уласны тыпу 8-бітны. Астатнія два будуць там.
дададзена аўтар Pete Becker, крыніца
Вы атрымалі адказы, якія адносяцца да «цёмнага» і «экзатычным» архітэктуры. Гэтыя тэрміны трохі прадузята. Вядома, калі ваш адзіны вопыт з настольнымі сістэмамі, гэтыя архітэктуры знаходзяцца за межамі дыяпазону вопыту. Але "я не бачыў гэтага раней» не тое ж самае, як «гэта невыразнае або экзатычнае». Для людзей, якія працуюць з убудаванымі сістэмамі або ЦСП гэтыя рэчы даволі часта.
дададзена аўтар Pete Becker, крыніца

6 адказы

uint_least8_t is the smallest type that has at least 8 bits. uint_fast8_t is the fastest type that has at least 8 bits.

Вы можаце ўбачыць адрозненні па сабе экзатычныя архітэктуры. Уявіце сабе 20-разрадную архітэктуру. Яго беззнаковое INT мае 20 біт (адзін рэгістр), і яго сімвал без знака мае 10 біт. Так SizeOf (INT) == 2 , але выкарыстоўваючы сімвал Тыпы патрабуе дадатковых інструкцый, каб скараціць рэгістры напалову. тады:

  • uint8_t: is undefined (no 8 bit type).
  • uint_least8_t: is unsigned char, the smallest type that is at least 8 bits.
  • uint_fast8_t: is unsigned int, because in my imaginary architecture, a half-register variable is slower than a full-register one.
72
дададзена
Я люблю, як вы павінны ўявіць сабе экзатычныя архітэктуры, каб знайсці спосаб выкарыстання гэтага. Ці ёсць у іх знайшлі якую-небудзь карысць на практыцы?
дададзена аўтар Mehrdad, крыніца
@skyking: Я пытаўся, ці былі тыпы <�б> карысна на любых архітэктурах. Іншымі словамі, людзі на самай справе выкарыстаць іх і атрымаць карысць з іх семантыкі праз архітэктуру? Або яны проста пыляцца або выкарыстоўваюцца, калі яны на самой справе не патрэбныя або карысныя?
дададзена аўтар Mehrdad, крыніца
Для тых, для каго гэта, магчыма, было незразумела - тое, што я спрабаваў сказаць раней, наступныя дзве рэчы: (1) Так, я бачыў, што некаторыя ультра-карэктных людзі выкарыстоўваюць [і] int_ {меры, хуткі} * _ т у кодзе, але (2) Я да гэтага часу не бачыў нікога зрабіць гэта, таму што ён падаў ім фактычнай выгады, а не гіпатэтычная. Іншымі словамі, у выпадках выкарыстання я бачыў, што людзі будуць мець (на практыцы) было так жа добра, ад выкарыстання непадпісаным Int або непадпісаныя сімвал або size_t або любы іншы.
дададзена аўтар Mehrdad, крыніца
@DevSolar: На жаль, семантыка мінімум і хутка тыпаў у выразах змешанага тыпу ўяўляюць сабой поўны беспарадак. Напрыклад, калі uint_least8_t х = 1; , што павінна быць значэнне х-2> 5 ?
дададзена аўтар supercat, крыніца
... да гэтага часу, як я ведаю, няма рэалізацый C, якія не выкарыстоўваюць дадатковы код дапаўненні калі-небудзь падтрымліваецца 64-бітным або больш без знака тыпу, што зрабіла б яго малаверагодны, што адпаведнае ня-дадатковы код дапаўненні C99 або C11 рэалізацыя будзе калі-небудзь існаваць.
дададзена аўтар supercat, крыніца
@EuriPinhollow: Пераўтварэнне з падпісаных тыпаў, каб без знака вызначаюцца такім чынам, што адымаючы любы станоўчы N з любога тыпу без знака, а затым дадаць N дасць зыходнае значэнне, калі вынік прымушае да зыходнага без знака тыпу [я кажу станоўчае значэнне, так як можна было б ладзіць дзіўна сістэму, дзе Int было 16 значэнняў бітаў, знакавы біт і 15 біт запаўнення і непадпісаным меў 16 бітаў значэнняў і 16 бітаў запаўнення, а uint16_t ранжыраваць ніжэй Int , дзе адніманне з -1 uint16_t дасць нявызначаны паводзіны ]. З другога боку, ...
дададзена аўтар supercat, крыніца
@EuriPinhollow: Рэалізацыі вольныя падтрымліваць uint16_t ці не, што робіць існаванне з uint16_t вызначаецца рэалізацыяй, але uint16_t а = 1 ; а- = 2; будзе ўсталяваны а 65535 на любы адпаведнай рэалізацыі, якая падтрымлівае uint16_t ня спасылаецца на «One Program Rule», каб апраўдаць рабіць нешта адвольна розныя.
дададзена аўтар supercat, крыніца
@DevSolar: С uint8_t не будзе ніякага цэлалікавага перапаўнення, так як 2 падпісаны. Магчыма, было б карысна мець асобны мінімум «лік» і «ўпакоўка алгебраічнага кольцы» тыпу, таму unum_least8_t можа быць любым - знак або без знака - які можа ўтрымліваць 0-255 і спрыяе знакавага тыпу , а uwrap_least8_t будзе тып, які спрыяе да чаго-то пры даданні, subtrated, памножанай і г.д. дасць вынік, дно 8 біт будзе як бы аперацыя былі выкананы на тыпу 8 біт.
дададзена аўтар supercat, крыніца
<�Код> int_fast32_t праўдападобна: у сітуацыях, калі вы звычайна карыстаецеся Int , але не хачу, каб разбіць на 16-бітную платформу
дададзена аўтар M.M, крыніца
Экзатычныя архітэктуры, як машыны з 9-бітнымі байтамі, зрабіць гэта лёгка зразумець. (Дарэчы, па меншай меры, адзін распаўсюджаны ESP мае 9-бітныя байты, а таксама 36-бітныя «слова» ў рэгістрах. Гэтыя дадатковыя біты выкарыстоўваюцца ў якасці ахоўных біт для прадухілення перапаўнення/насычэння. Яны выкідваюцца пры захоўванні ў памяць.)// Але, гэта ставіцца нават да агульных RISCs з 32-бітнымі інструкцыямі рэг-рэг. uint8_t запатрабуе ўсячэнне - напрыклад, з дапамогай AND або магазін -байт/загрузкі байта - пасля кожнай аперацыі uint8_t. Я думаю, што uint_fast8_t дазволена часам пакараціць, а часам няма, нават SizeOf (uint8_t) == SizeOf (uint_fast8_t).
дададзена аўтар Krazy Glew, крыніца
@supercat: «Не спадзявацца на цэлалікавых перапаўненне/семантыкі для ніжняга, без знака ці не»?
дададзена аўтар DevSolar, крыніца
@Mehrdad: Перавага ў кантэксце. Калі вы пішаце непадпісаным Int , не ясна, <�я> чаму вы выкарыстоўвалі <�я>, што тыпу (а не які-небудзь іншы). Гэта таму, што <�я> дакладна </я> 32 біт, ці таму, што <�я> прынамсі </я> 32 біт? Ці гэта таму, што гэта «самы хуткі» тып? (О <�я> Ваш </я> платформа ...) Я - у якасці падтрымлівае кодэрам - не ведаю, вашыя намеры пры дапамозе непадпісаным Int , і я сумняваюся, што гэта можа недапушчальны тып у кантэксце (і, такім чынам, адказнасць за памылку я паляванне). Калі вы напісалі uint_least32_t , ваш <�я> Намер ясна, і я магу пераправерыць, калі вашы здагадкі былі/з'яўляюцца правільнымі.
дададзена аўтар DevSolar, крыніца
@plugwash: х з'яўляецца неад'емным павышаны да аднімання, таму, калі яго тып мае той жа памер, як Int ён будзе павышаны да непадпісанага INT і вынік будзе сапраўдным. Калі ён менш будзе прызначаны Int і вынік будзе ілжывым.
дададзена аўтар rodrigo, крыніца
@skyking: Вядома, яны карысныя, у тэорыі. Але я хутка Grep праз зыходны код некалькі папулярных праграм і бібліятэк АС у мяне ёсць вакол, і толькі выкарыстанне гэтых тыпаў у укаранёных копіі stdint.h . І гэты загаловак патрабуецца толькі для uintX_t Ones.
дададзена аўтар rodrigo, крыніца
@skyking: Я не кажу, што яны не павінны выкарыстоўвацца, так што яны не выкарыстоўваюцца вельмі на практыцы. Калі вы можаце знайсці рэальнае дадатак або бібліятэку, якая выкарыстоўвае іх асэнсавана, а затым размясціць спасылку, таму што я не мог знайсці.
дададзена аўтар rodrigo, крыніца
@Mehrdad: Я прызнаю, што я ніколі не бачыў uint_leastX_t або uint_fastX_t выкарыстоўваецца ў рэальных прыкладаннях. <�Код> uintX_t так, яны актыўна выкарыстоўваюцца. Падобна на тое, што людзі не вельмі цікава ў пераноснасці экзатычных архітэктур. Які, як чакаецца, нават калі вы атрымаеце ваша unsigneds правы, ваша праграма не зможа на тысячу розных рэчаў.
дададзена аўтар rodrigo, крыніца
@ M.M: Fixed, дзякуй.
дададзена аўтар rodrigo, крыніца
@Mehrdad: ... і калі вы программируете для экзатычнай архітэктуры, то вы ведаеце, вашыя тыпаў, вы наўрад ці пісаць код карысны для іншага кампутара, так што вы не клапоціцеся аб пераноснасці.
дададзена аўтар rodrigo, крыніца
@rodrigo Чаму б не клапаціцца аб пераноснасці? Мой вопыт паказвае, што людзі на асноўнай архітэктуры, больш схільныя лічыць, што кожная платформа, якая паводзіць сябе трохі адрозніваецца «зламаны" і што адзін не прыйдзецца клапаціцца аб Int не з'яўляецца прыдатным для захоўвання паказальніка.
дададзена аўтар skyking, крыніца
@Mehrdad я б сказаў, што гэта вельмі карысна, па меншай меры, * int_least * _t і uint_fast * _t . Яны гарантавана існуюць і гарантавана мець заяўлены дыяпазон - гэта азначае, што код на самай справе становіцца пераносным. Вядома, можна было б сцвярджаць, што можна было б выкарыстоўваць Int замест int_least16_t і доўгай замест int_least32_t (але звернеце ўвагу, як гэта прымушае вас выкарыстоўваць 32-разрадныя колькасці замест 16-бітных, дзе 16-біт даступны, або 64-разрадныя колькасці замест 32-бітнай, дзе 32-біт даступны).
дададзена аўтар skyking, крыніца
@rodrigo Так, у тэорыі варта мець справу з цэлалікавых перапаўненнем, але на практыцы гэта, здаецца, што праграмісты проста выкажам здагадку, што тыя не адбываецца (гэта прыходзіць Y2K, што не павінна адбыцца).
дададзена аўтар skyking, крыніца
@Mehrdad MIPS, напрыклад, было б вельмі няправільна рабіць якія-небудзь uintX_fast_t менш, чым 32 біта. Вы не павінны нават уявіць архітэктуру, каб атрымаць uint8_t , каб быць нявызначаным, вазьміце, напрыклад, UNIVAC, які 36-біт, я б выказаць здагадку, што сімвал з'яўляецца 9- няшмат.
дададзена аўтар skyking, крыніца
«Напрыклад, пры uint_least8_t х = 1;?, Што павінна быць значэнне х-2> 5» 1, калі сімвал мае такі ж памер, як INT 0, калі сімвал менш, чым Int.
дададзена аўтар plugwash, крыніца
@Mehrdad У ARM, напрыклад, калі ваш int_fast8_t гэта 32-бітная пераменная, вам не трэба рабіць знакавая перад тым arithmetric аперацый.
дададзена аўтар user694733, крыніца
@supercat вы маеце рацыю, стандарт на самай справе кажа, што: eel.is/c++draft /conv.integral#2 хоць і не толькі двайковае дадатак дапускаецца.
дададзена аўтар Euri Pinhollow, крыніца
@supercat калі вы пішаце UINT [ANY] _t а = 1; а-2; выкарыстоўваецца пэўнай рэалізацыяй паводзін, і гэта выразна паказана ў стандарце.
дададзена аўтар Euri Pinhollow, крыніца
@merhad: Я працаваў з працэсарам, які быў толькі 32-бітныя значэння для ўсяго. (На самай справе 40 біт, але кампілятар зрабіў усё ў 32-бітных значэнняў), так што не было uint8_t або uint16_t, але uint32_t і ўсё uint_least * і * uint_fast тыпы былі такімі ж, як uint32_t. Гэта быў ADSP SHARC. У маім бягучым праекце мы выкарыстоўваем хуткі і найменш тыпаў шмат.
дададзена аўтар Florian Keßeler, крыніца

uint8_t means: give me an unsigned int of exactly 8 bits.

uint_least8_t means: give me the smallest type of unsigned int which has at least 8 bits. Optimize for memory consumption.

uint_fast8_t means: give me an unsigned int of at least 8 bits. Pick a larger type if it will make my program faster, because of alignment considerations. Optimize for speed.

Акрамя таго, у адрозненне ад звычайнага кода <> Int Тыпы, падпісаная версія вышэйзгаданых тыпаў stdint.h гарантавана будуць у фармаце дапаўненні 2 ст.

21
дададзена
@Lundin: Любы канкрэтны кампілятар, хутчэй за ўсё, вызначыць «int32_t» і «uint32_t» на «INT» і «без знака Int», або «доўгія» і «без знака доўга». Праблема заключаецца ў тым, што на платформах, дзе «ИНТ» і «доўгія» з'яўляюцца абодва 32 біта, няма асаблівых падстаў чакаць «int32_t» быць адзін памер ці іншай. Калі адзін праходзіць масівы бібліятэк, якія выкарыстоўваюць * Int , * доўгі і * int32_t , няма ніякага спосабу, каб зрабіць адзін масіў быць сумяшчальныя з усе тры <�я> нават на платформах, дзе ўсе тры тыпу маюць аднолькавы памер і прадстаўленне .
дададзена аўтар supercat, крыніца
@Lundin: Некаторыя кампілятары выкарыстоўваюць «доўгія» як ЬурейиЕ для int32_t, а некаторыя выкарыстоўваюць «ИНТ». Нават калі «ИНТ» і «доўгі» мае такое ж уяўленне, яны могуць быць (і часам) лічацца розным для мэт правілаў накладання спектраў Кассиопеяна.
дададзена аўтар supercat, крыніца
@ Legends2k: Тыпы ў stdint.h з'яўляецца значна менш карысным, чым адзін можа спадабацца, калі адзін спрабуе пісаць пераносны код, так як у той час як яны павінны выкарыстоўваць фармат захоўванне дадатковага кода камлементу, гэта не азначае, што яны будуць дэманстраваць комплемент дадатковага кода паводзін абгортачнай. Заўважым таксама, што нават на платформах, дзе Int 32 біта , запіс значэння з дапамогай int32_t * і чытання з дапамогай Int * , ці наадварот, не гарантуецца.
дададзена аўтар supercat, крыніца
Дзякуючы. Важна ведаць, што падпісаныя тыпы ў stdint.h гарантавана двайковае дадатак. Цікава, дзе гэта дапаможа пры напісанні пераноснага кода.
дададзена аўтар legends2k, крыніца
@supercat Не было б даволі дурное кампілятарам як вызначэнне тыпу ць тыпу, які выклікае канфлікт з кожным уласнай апрацоўкі накладання? Падобна на тое, праблема для незалежнай ад платформы кампілятараў толькі (GCC), дзе порт кампілятар для дадзенага апаратнага забеспячэння не мае ніякага кантролю над тым, як гэта робіцца паказальнік псеўданімы?
дададзена аўтар Lundin, крыніца
@supercat Кожнага кампілятара я бачыў выкарыстоўваць унутраныя ЬурейиЙ для тыпаў stdint.h, каб зрабіць іх сінонімы з адным з асноўных «ключавых слоў» цэлалікавых тыпаў. Так што калі вы турбуецеся аб паказальніку псеўданімаў я не думаю, што гэта будзе праблемай на практыцы, толькі ў тэорыі.
дададзена аўтар Lundin, крыніца
Звярніце ўвагу, што толькі дакладныя варыянты шырыні неабходна выкарыстоўваць фармат камлементу 2 ст. Таксама зьвярніце ўвагу, што яны не абавязаны існаваць. Такім чынам, платформа не патрабуецца для падтрымкі фармату камлементу 2 ст.
дададзена аўтар skyking, крыніца

Тэорыя абвяшчае, што нешта накшталт:

uint8_t is required to be exactly 8 bits but it's not required to exist. So you should use it where you are relying on the modulo-256 arithmetic behaviour of an 8 bit integer and where you would prefer a compile failure to misbehaviour on obscure architectures.

uint_least8_t is required to be the smallest available unsigned integer type that can store at least 8 bits. You would use it when you want to minimise the memory use of things like large arrays.

uint_fast8_t is supposed to be the "fastest" unsigned type that can store at least 8 bits; however, it's not actually guaranteed to be the fastest for any given operation on any given processor. You would use it in processing code that performs lots of operations on the value.

Практыка такая, што «хуткі» і «найменш» тыпы не выкарыстоўваецца.

«Найменш» тыпы толькі вельмі карысна, калі вы клапоціцеся аб пераноснасці зацямняць архітэктуры з CHAR_BIT! = 8, які большасць людзей гэтага не робяць.

Праблема з «хуткімі» тыпамі з'яўляецца тое, што «хуткім» цяжка прыціснуць. Меншы тып можа азначаць меншую нагрузку на сістэму памяці/кэш, але з выкарыстаннем тыпу, які менш, чым натыўны можа запатрабаваць дадатковых інструкцый. Акрамя таго, што лепш за ўсё можа перамыкацца паміж версіямі архітэктуры, а выканаўцы часта хочуць, каб пазбегнуць парушэнні ABI ў такіх выпадках.

Гледзячы на ​​некаторых папулярных рэалізацый, здаецца, што вызначэння uint_fastn_t дастаткова адвольна. Glibc, здаецца, вызначыць іх як па меншай меры, «родны памер словы» сістэмы ў пытанні не прымаючы да ўвагі той факт, што многія сучасныя працэсары (асабліва 64-бітныя) маюць пэўную падтрымку для хуткіх аперацый на дэталях менш, чым іх роднае слова памер. IOS, відаць вызначае іх як эквівалентныя тыпы фіксаванага памеру. Іншыя платформы могуць адрознівацца.

Увогуле, калі прадукцыйнасць тугі коды з малюсенькімі цэлым вашай мэтай, вы павінны быць бенчмаркетынгу <�моцнага> Вашага кода на платформах вы клапоціцеся аб з рознымі тыпамі памераў, каб убачыць, што працуе лепш за ўсё.

20
дададзена
@zwol: Я хачу мова бы дадаць тыпы тыпаў, якія былі вызначаны з пункту гледжання размяшчэння і семантычных патрабаванняў, напрыклад, «Мне трэба нешта, чые малодшыя біты будзе псеўданім іншых тыпаў 16-разрадных, і які можа ўтрымліваць значэння 0-65535, але мне гэта не трэба прывязваць вялікія значэння для гэтага дыяпазону». Скажэнні, размяшчэнне, дыяпазон, і з-за мяжы дыяпазону паводзіны павінна быць чатыры асобныя аспекты тыпу, але З дапускае толькі пэўныя камбінацыі, якія не адпавядаюць паміж рознымі платформамі.
дададзена аўтар supercat, крыніца
Вызначэння GLibC былі выбраны ў той час, калі гэтыя аптымізацыі не існуе, і цяпер яны запечаныя ў ABI і не могуць быць змененыя. Гэта адна з некалькіх прычын, чаму _least і _fast тыпаў не з'яўляюцца на самай справе карысныя на практыцы.
дададзена аўтар zwol, крыніца

Некаторыя працэсары не могуць працаваць так жа эфектыўна, на невялікіх тыпаў дадзеных, як і на вялікіх. Напрыклад, улічваючы:

uint32_t foo(uint32_t x, uint8_t y)
{
  x+=y;
  y+=2;
  x+=y;
  y+=4;
  x+=y;
  y+=6;
  x+=y;
  return x;
}

калі у былі uint32_t кампілятар для ARM Cortex-M3 можа проста генераваць

add r0,r0,r1,asl #2   ; x+=(y<<2)
add r0,r0,#12         ; x+=12
bx  lr                ; return x

але так як у гэта uint8_t кампілятар павінен быў бы замест генерацыі:

add r0,r0,r1          ; x+=y
add r1,r1,#2          ; Compute y+2
and r1,r1,#255        ; y=(y+2) & 255
add r0,r0,r1          ; x+=y
add r1,r1,#4          ; Compute y+4
and r1,r1,#255        ; y=(y+4) & 255
add r0,r0,r1          ; x+=y
add r1,r1,#6          ; Compute y+6
and r1,r1,#255        ; y=(y+6) & 255
add r0,r0,r1          ; x+=y
bx  lr                ; return x

Вызначаная мэта «хуткіх» тыпаў павінна была дазволіць кампілятара замяніць меншыя тыпы, якія не могуць быць апрацаваны эфектыўна з больш хуткімі. На жаль, семантыка «хуткіх» тыпаў даволі дрэнна вызначаны, у сваю чаргу, пакідае мутныя пытанні, ці будзе ацэньвацца з выкарыстаннем знакам або без знака матэматычных выразаў.

4
дададзена
@Galaxy: На жаль, стандарт не дапушчае магчымасці «найменш» тыпаў, паводзіны якіх можа мяняцца ў залежнасці ад кантэксту. На многіх машынах, напрыклад, арыфметыку на 32-разрадных значэнняў у рэгістрах можа быць хутчэй, чым аперацыі з выкарыстаннем 8-бітных значэнняў у рэгістрах, але 8-бітныя нагрузкі і захоўвае бы з той жа хуткасцю, як 32-разрадных нагрузак і крам, і кэшаванне праблемы могуць прывесці да 8-бітным значэнняў, каб быць больш эфектыўнымі.
дададзена аўтар supercat, крыніца
Дадатковыя патэнцыйна непатрэбныя інструкцыі пры працы з меншым тыпам дадзеных супраць большага тыпу дадзеных роднага памеру словы прайсці доўгі шлях, каб праілюстраваць, чаму многія з «хуткіх» тыпаў дадзеных могуць мець вялікую разраднасць, чым чакалася. Дзякуй вам за ваш прыклад.
дададзена аўтар Galaxy, крыніца
<�Р> 1.Can вы растлумачыць, што гэта значыць «гэта беззнаковое INT, па меншай меры, 8 біт»?

Гэта павінна быць відавочна. Гэта азначае, што гэта цэлы лік без знака тыпу, і што гэта шырыня складае па меншай меры 8 біт. Фактычна гэта азначае, што ён можа, па меншай меры ўтрымліваць лік ад 0 да 255, і ён вызначана можа не трымаць адмоўныя лікі, але гэта можа быць у стане трымаць лік вышэй, чым 255.

Відавочна, што вы не павінны выкарыстоўваць любога з гэтых тыпаў, калі вы плануеце захоўваць любую колькасць па-за дыяпазону ад 0 да 255 (і вы хочаце, каб быць партатыўнымі).

<�Р> 2.How uint_fast8_t і uint_least8_t дапамагаюць павысіць эфектыўнасць/код прасторы ў параўнанні з uint8_t?

uint_fast8_t is required to be faster so you should use that if your requirement is that the code be fast. uint_least8_t on the other hand requires that there is no candidate of lesser size - so you would use that if size is the concern.


І, вядома, выкарыстоўваць толькі uint8_t , калі вы абсалютна патрабуюць, каб быць роўна 8 біт. Выкарыстоўваючы uint8_t можа зрабіць код невыноснымі, як uint8_t не патрабуецца, каб існаваць (таму што такі маленькі цэлалікавых тып не існуе на пэўных платформах).

4
дададзена

У «хуткіх» цэлых тыпах вызначаюцца быць самым хуткім лікам даступныя па меншай меры, колькасць біт, патрэбных (у вашым выпадку 8).

Платформа можа вызначыць uint_fast8_t як uint8_t , то не будзе абсалютна ніякай розніцы ў хуткасці.

Прычына заключаецца ў тым, што ёсць платформы, якія павольней, калі вы не выкарыстоўвае іх родную даўжыню слова.

3
дададзена