Küsimus:
Kuidas on parim viis I / O-tihvti määratleda?
Joris Groosman
2015-04-27 11:11:54 UTC
view on stackexchange narkive permalink

Lugesin selliseid definitsioone nagu

  const int ledPin = 9;  

ja ka

  #define ledPin 9 

Ma tean, et selline definitsioon nagu

  int ledPin = 9;  

on halb tava, kui ma ei hakka seda muutma (mida te tavaliselt ei tee), ehkki näen seda Arduino programmides mitu korda. Millist teistest eelistatakse?

Neli vastused:
user8688
2015-04-27 12:06:32 UTC
view on stackexchange narkive permalink
Eelistatud on

#define ledPin 9 . Tehes int ledPin = 9; , eraldate mälu int , mille väärtust kasutatakse iga kord, kui kasutate ledPin . #define on selles mõttes erinev, et see ei eralda mälu. pole mälu nimega ledPin . Enne kõigi koodi "ledPin" kompileerimist (v.a stringid) asendatakse koodiga 9 . Nii et põhimõtteliselt

digitalWrite(ledPin);

saabub

  digitalWrite (9);  

#define eelised: säästab mälu ja kuna kõik ledPin asendatakse enne käivitamist koodiga 9 , see säästab protsessori aega.

Pole väikeste koodidega tegelikult oluline ...

Kas manustatud kompilaatorid on tõesti nii halvad, et ei tee `const int` kasutamisel pidevat voltimist?
@chuu minu teada kasutab Arduino avr jaoks gcc-d. Nii et see tuleks peaaegu kindlasti välja optimeerida. Siinsed vastused ei näita C ++ hea tava mõistmist eriti palju
C ++ puhul on "const int ledPin = 9;" eelistatud kahe muu variandi asemel. See EI eralda mälu `int'-le, välja arvatud juhul, kui määrate sellele kusagil osuti, mida keegi ei teeks.
Const int eraldab mälu @jfpoilpret. #define ei kasuta ühtegi mälu, sest see on ainult väljendi sümboolne nimi, mitte mälu nimi ...
Vaadake seda linki http://www.cplusplus.com/forum/beginner/28089/ ja veenduge ise. Muul juhul tehke lihtsalt kontroll Arduino IDE-ga: kontrollige andmete suurust constiga ja #define.
#define pole isegi ruumi võtmiseks vajalik andmetüüp. Link ei ütle mälu kohta midagi. Igatahes toob see välja const-i eelise ulatuse osas ...
Peter Bloomfield
2015-04-27 14:19:19 UTC
view on stackexchange narkive permalink

Rangelt võttes kulutab lähenemine #define veidi vähem mälu. Erinevus on tavaliselt siiski väike. Kui peate vähendama mälukasutust, oleksid muud optimeerimised tõenäoliselt palju tõhusamad.

Argument const int kasutamise kasuks on type safety . Ükskõik kuhu viite sellele PIN-koodile muutuja järgi, teate täpselt, millise andmetüübi saate. Seda võib kaudselt või otseselt reklaamida / teisendada kood, mis seda kasutab, kuid see peaks käituma väga selgelt.

Seevastu väärtus #define on avatud tõlgendamisele. Valdav osa ajast ei põhjusta see teile tõenäoliselt üldse probleeme. Peate lihtsalt olema veidi ettevaatlik, kui teil on kood, mis teeb eeldusi väärtuse tüübi või suuruse kohta.

Isiklikult eelistan ma peaaegu alati tüübi ohutust, kui mul pole väga tõsist vajadust mälu salvestada.

Olin #define laagris, kuni lugesin Peetruse vastust. Arvan, et tean, kes sel nädalavahetusel koodi uuesti parandab. ;)
rykien
2015-04-27 22:28:15 UTC
view on stackexchange narkive permalink

Ilmselt parim viis oleks
const uint8_t LED_PIN = 9; // võib nõuda # lisada <stdint.h>
või
const bait LED_PIN = 9; // ilma kaasata vajalik
const allkirjastamata märg LED_PIN = 9; // sarnaselt
Nimi on konstantide nimetamiseks suurtähtedega vastavalt C ++ (ja teiste) tavapraktikale. See ei tohiks iseenesest kasutada ühtegi RAM-i ja kasutada umbes 1 baiti programmimälu ühe kasutuskorra kohta.
Siiski võib võib olla probleeme, kui number on suurem kui 127 ja selle laiendamisel on märgiga pikendatud reklaamitakse suuremate signeeritud täisarvudeni (pole selles täiesti kindel), kuigi pin-numbritega see tõenäoliselt ei juhtu.

JRobert
2015-04-27 19:30:32 UTC
view on stackexchange narkive permalink

Peale selle, et

  const int ledPin = 9;  

võtab RAM-i, kuid kasutab sel juhul rohkem RAM-i kui vaja, nagu digitalWrite (uint8_t, uint8_t) vajab ainult ühebaidiseid argumente ja int on tavaliselt kaks baiti (sõltuv kompilaatorist, kuid tüüpiline). Pange tähele, et saate otsesõnalisele otsetüübi anda määratluses #define:

  #define ledPin ((int) 9) 

kuigi sellises kontekstis funktsiooni argumendina, kus on vaja konkreetset tüüpi (kuna funktsioon oli korralikult prototüüpitud!), Kas see valitakse kaudselt või saadetakse tõrketeade, kui tüübid ei ühti.

@DrivebyDownvoter, kommenteeriksite oma põhjuseid?


See küsimus ja vastus tõlgiti automaatselt inglise keelest.Algne sisu on saadaval stackexchange-is, mida täname cc by-sa 3.0-litsentsi eest, mille all seda levitatakse.
Loading...