void akadályrobot hoz tanultam programozni, de amikor megnéztem kódot két hosszú és hosszú adattípust láttam. Hosszúak azok az adattípusok is, amelyek -2 147 483 648 és 2 147 483 647 értékeket tartalmaznak.
Az Int és a hosszú megegyezik, de előálltam azzal a kóddal, ahol kétféle adattípust használunk, az alábbiak szerint: “7c70f69706”>
De honnan lehet tudni, hogy melyik adattípust mikor kell használni? Sokat keresgéltem az interneten, de nem értettem, ezért tudná ezt valaki elmagyarázni nekem.
Megjegyzések
- ” Int olyan adattípus, amely -2 147 483 648 – 2 147 483 647 ” Hol hallotta ezt?
Válasz
Az Arduino (AVR modellek) esetében egy int 16, nem 32 bit. Így -32768-ról +32767-re változik.
Ez eltér long ami 32 bites.
Megjegyzések
- Mekkora a
intéslonga 32 bites ARM Arduinos-on, például az Due miatt? - Úgy gondolom, hogy a Due miatt egy
int32 bit, ugyanaz along. Lásd például itt .
Válasz
int az AVR GCC-ben 16 bitek , nem 32.
Válasz
A C nyelv specifikációja szerint , a int legalább 16 bitesnek és a long legalább 32 bitesnek kell lennie.
A fordító számára rendben van, ha a int fájlt 32 vagy akár 64 bitként valósítja meg. A fordító számára rendben van, ha a long fájlt 64 bites vagy annál hosszabb ideig hajtja végre. De a fordító számára nem engedélyezett a long 16 bitként való megvalósítása.
Tehát mikor melyik típust használja?
Ha az értékek amellyel dolgozni fog, 16 biten belül képviselhető, akkor rendben van a int használata. Ha 16-nál több bitre van szüksége, használja a long. Ha 32 bitnél többre van szüksége, használja a következőt: long long.
Ne érje a fordító és / vagy a CPU sajátosságait. Amint mások már említették, még a ugyanaz a termékcsalád, az Arduinos, 16 és 32 bites CPU-k állnak rendelkezésre. Ehelyett csak abban bízzon, amit a szabvány garantál.
A C típusok teljes specifikációja:
-
charlegalább 8 bit legyen -
intlegalább 16 bit -
longlegalább 32 bitesnek kell lennie -
long longlegalább 64 bitesnek kell lennie
Megjegyzés: A fordítók számára teljesen legális a char, int, long és long hosszúságú implementáció mint 64 bit. Ez valójában nem ritka a DSP-k körében.
Megjegyzések
- Továbbá: Olvassa el a fordító dokumentációját
- És:
sizeof(char) <= sizeof(int) <= sizeof(long) <= sizeof(long long)a szabvány szerint. Tehát, ha aint64 bit, akkor along-nek is legalább 64 bitnek kell lennie.
Válasz
Ugyanaz az érvelés, mint a C-ben: a int típus mérete várható az a természetes szóméret, amelyet a rendszer a leghatékonyabban kezel . Legalább 16 bit szélesnek kell lennie, nem lehet kisebb, mint egy short, és nem lehet nagyobb mint egy long.
Tehát egy int 16, 32 vagy 64 bites lehet bármi, amit a rendszere legjobban kezel, és így valószínűleg 16 bit széles lesz egy 8 vagy 16 bites CPU-n, 32 egy 32 bites CPU-n stb.
A “2ebfa52def”>
amikor a legjobb teljesítményt akarom, miközben vigyázok arra, hogy vigyázzak, ha nagyobb hatótávolságra van szükségem, mint amennyit 16 bit kínál. Manapság hajlamos vagy tudni, mikor írsz alkalmazáskódot 16 bites rendszerekhez, bár ez nem annyira igaz a “könyvtár” kódra, ahol a hordozhatóság lehet nagyobb aggodalomra ad okot.
A példádban, feltételezve, hogy a szerző gondosan választotta ki a típusaikat, a int változók valószínűleg kis tartományt igényelnek, és megengedhetik maguknak, hogy szóméretűek legyenek , ami rövidebb vagy gyorsabb kódhoz (vagy mindkettőhöz) vezet. A long feltehetően több mint 16 bites tartományra van szükség (garantáltan legalább 32 bit széles). A fordítási célként kiválasztott processzoron úgy tűnik, hogy a int és a long fájlok egyaránt 32 bitesek lettek megvalósítva; legyen más (vagy kell legyen), ha 16 bites cél CPU-t választott.
Válasz
Szeretem használni a következő típusokat: stdint.h.
Noha vannak kisebb hátrányaik, az az előnyük, hogy pontosan ismeri a méretet, még akkor is, ha más architektúrákon áll össze.
#include <stdint.h> uint8_t my_byte = 0xf0; int16_t trig_pin = 2; int16_t echo_pin = 4; uint32_t duration, cm , blah; uint64_t big_int; // etc. De nyilvánvalóan nem akar egy csomó int32_t körül mozogni, amikor az adatainak csak int16_t-re van szükségük.
Megjegyzések
- Tehát ne gépi szót használjon A méret nem befolyásolja az AVR teljesítményét?
- @Ren é – Általában a szóméret hiánya hatással lehet a legtöbb CPU teljesítményére. De hagyományosan az AVR CPU-k 8 bites regiszterekkel rendelkeznek & akkumulátorok, mintegy 16 bites utasításokkal a mutatóműveletekhez. Tehát amikor programozok, először a kódot futtatom, majd optimalizálom a sebességet ha ez ‘ s túl lassú.
- @Ren é – De ha valóban pedáns akar lenni benne, használhatja
wordmint adattípus. Ez 16 bit az Arduino Uno-n, és 32 bit az Arduino Due & Zero esetén. De ez visszatér arra a problémára, hogy valóban csak az adattípus minimális méretét ismerjük. Tegyük fel, hogy aword-t használja valamilyen Due kódon, de aztán vissza akarja kapcsolni Unót ?! Helyette az uint32_t használata megoldaná ezt a problémát, még mielőtt elindulna, de igen, a szó mérete optimálisabb lesz az Uno-n. Mi van a jövő Arduino táblákkal … milyen méretű szavak lesznek? 32? 64? 128 !? - OK. Tehát a gépi szó méretét használnám (az int? A WORD obselete windows típusú definíciónak tűnik), ha az alsó határ elegendő, nem érdekel a memória mérete, és szükségem van a sebességre, * _t ha érdekel a méret?
- selejt, hogy … gnu.org/software/libc/manual/html_node/Integers.html mondja
*fast*_tjárható út …