Jeg lærte å programmere for en tom hindringsrobot men da jeg så på kode Jeg så to datatyper lange og int.
Int er datatyper som inneholder -2,147,483,648 til 2,147,483,647. Lang er også datatyper som inneholder -2,147,483,648 til 2,147,483,647.
Int og lang er som de samme, men jeg kom på koden der to typer datatype brukes som vist nedenfor:
int trigPin = 2; int echoPin = 4; long duration, cm, inches; Men hvordan kan du vite når du skal bruke hvilken datatype? Jeg søkte mye på nettet, men jeg forstod det ikke, så kan noen forklare dette for meg.
Kommentarer
- " Int er datatyper som inneholder -2,147,483,648 til 2,147,483,647 " Hvor hørte du det?
Svar
På Arduino (AVR-modeller) er en int 16 bits, ikke 32 bits. Dermed går den fra -32768 til +32767.
Det er forskjellig fra long som er 32 bits.
Kommentarer
- Hva er bredden på
intoglongpå 32-biters ARM Arduinos som Due? - Jeg tror på grunn at en
inter 32 biter, det samme erlong. Se for eksempel her .
Svar
int i AVR GCC er 16 bits , ikke 32.
Svar
I henhold til C-språkspesifikasjonen , int må være minst 16 bits eller lenger, og long må være minst 32 bits eller lenger.
Det er OK for en kompilator å implementere int som 32 bits eller til og med 64 bits. Det er OK for en kompilator å implementere long som 64 bits eller lenger. Men det er ikke tillatt for en kompilator å implementere long som 16 bits.
Så når skal du bruke hvilken type?
Hvis verdiene du vil jobbe med kan representeres innen 16 bits, så er det OK å bruke int. Hvis du trenger mer enn 16 bits, bruk long Hvis du trenger mer enn 32 bits, bruk long long.
Ikke bli fanget opp av kompilator- og / eller CPU-spesifikasjoner. Som nevnt av andre, selv innen det samme produktsortimentet, Arduinos, det er 16 og 32-biters CPUer tilgjengelig. Stol i stedet bare på hva standarden garanterer. > char må være minst 8 bits
int må være minst 16 bits long må være minst 32 bits long long må være minst 64 bits Merk: Det er helt lovlig for kompilatorer å implementere røye, int, lang og lang lang som 64 bits. Dette er faktisk ikke uvanlig blant DSP-er.
Kommentarer
- Også: Les kompilatordokumentasjonen din
- Og:
sizeof(char) <= sizeof(int) <= sizeof(long) <= sizeof(long long)i henhold til standard. Så hvisinter 64 bits, målongogså være minst 64 bits.
Svar
Det er samme resonnement som i C: størrelsen på int -typen forventes å være den naturlige ordstørrelsen som systemet ditt håndterer mest effektivt . Det må også være minst 16 bits bredt, ikke mindre enn en short, og ikke større enn en long.
Så en int kan være 16-, 32- eller 64-bits, basert uansett hva systemet ditt håndterer best, og det er sannsynlig at det er 16 bits bredt på en 8- eller 16-biters CPU, 32 på en 32-biters CPU osv.
Jeg bruker int når jeg ønsker best ytelse, samtidig som jeg tar vare på når jeg trenger mer rekkevidde enn 16 bits. I disse dager pleier du å vite når du skriver applikasjonskode for 16-biters systemer, selv om det ikke er så sant for «bibliotek» -kode der bærbarhet kan være av større bekymring.
I ditt eksempel, forutsatt at forfatteren hadde valgt typene nøye, krever int variablene sannsynligvis et lite område og hadde råd til å være ordstørrelse. , noe som fører til potensielt kortere eller raskere kode (eller begge deler). long antok antagelig mer enn 16-biters rekkevidde (de er garantert minst 32 bits brede). På prosessoren du valgte som et kompileringsmål, ser det ut til at int og long ble implementert som 32-bit. være annerledes (eller skal være) hvis du valgte en 16-biters mål-CPU.
Svar
Jeg liker å bruke typer fra stdint.h.
Selv om de har mindre ulemper, er fordelen de gir at du vet nøyaktig størrelsen du håndterer, selv når du bygger på andre arkitekturer.
#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. Men åpenbart vil du ikke bevege deg rundt en rekke int32_t når dataene dine bare trenger int16_t.
Kommentarer
- Så ikke bruker maskinord størrelse påvirker ikke ytelsen på AVR?
- @Ren é – Generelt kan ikke bruk av ordstørrelse påvirke ytelsen på de fleste CPUer. Men tradisjonelt har AVR-CPUer 8-biters registre & akkumulatorer med noen 16-biters instruksjoner for pekeroperasjoner. Så når jeg programmerer, får jeg koden til å kjøre først, så optimaliser for hastighet hvis den ' er for sakte.
- @Ren é – Men hvis du virkelig vil være pedantisk om det, kan du bruke
wordsom datatype. Dette er 16 bits på Arduino Uno, og 32 bits på Arduino Due & Null. Men dette kommer tilbake til problemet med egentlig bare å vite minimumstørrelsen på datatypen din. Si at du brukerwordpå en eller annen forfallskode, men vil deretter backportere til Uno ?! Å bruke uint32_t i stedet vil løse dette problemet før det starter, men ja det vil være ordstørrelse suboptimal på Uno. Hva med fremtidige Arduino-tavler … hvilken ordstørrelse vil de ha? 32? 64? 128 !? - OK. Så jeg vil bruke maskinens ordstørrelse (int? WORD ser ut til å være en ubegrenset definisjon av Windows-typen) hvis nedre grense er tilstrekkelig, bryr jeg meg ikke om minnestørrelse og trenger hastigheten, * _t hvis jeg bryr meg om størrelse?
- skrot som … gnu.org/software/libc/manual/html_node/Integers.html sier
*fast*_tser ut til å være veien å gå …