ho letto che il tipo bool, anzichè occupare un bit in memoria, (come mi sarei aspettato), prende invece 8 bit (1 byte) di memoria: perchè? è un discorso legato al bus di dati?
perchè durante le classiche dichiarazioni degli stati dei led (ad esempio) vengono dichiarati come interi e non come booleani? ad esempio:
int statoLed = LOW;
digitalWrite(3, statoLed);
anche in questo caso mi aspetterei di avere una dichiarazione di una variabile bool anzichè int in quanto dovrebbe occupare meno memoria.
ho letto che il tipo bool, anzichè occupare un bit in memoria, (come mi sarei aspettato), prende invece 8 bit (1 byte) di memoria: perchè? è un discorso legato al bus di dati?
Probabilmente è una scelta del compilatore.
perchè durante le classiche dichiarazioni degli stati dei led (ad esempio) vengono dichiarati come interi e non come booleani?
Infatti è meglio usare un tipo a 8 bit (char, byte, uint8_t) anziché a 16 bit come un int.
Diciamo che una variabile booleana per chiarezza dovrebbe avere un nome che è una domanda (a cui rispondere true o false) e dovrebbe essere usata nelle espressioni logiche, mentre i tipi interi dovrebbero servire solo a manipolare valori numerici.
Che poi molte cose si possano interscambiare (perché alla fine sempre e solo di 1 e 0 si tratta) è un'altra storia.
In particolare HIGH e LOW (che sono sempre 1 e 0) si dovrebbero usare solo per i livelli di ingresso/uscita dei pin, ed essendo valori numerici ha senso trattarli con tipi byte.
in questo caso la minima memoria utilizzata è 1 byte...nel senso che se dichiari una variabile come bool questa occuperà 8 bit.
spesso negli esempi non si fa caso all'uso della memoria e quindi si utilizzano "int" per numeri/valori che potrebbero essere tranquillamente contenuti in un byte.
altra cosa...in arduino i valori true/false, HIGH/LOW hanno un volore numerico rispettivamente di 0 ed 1; di conseguenza l'IDE di arduino (passatemi l'affermazione) non è in grado di verificare se un confronto è fatto tra, o restituisce realmente, un bool; il controllo viene fatto sul valore di ritorno che può essere 0 (quindi falso) o diverso da 0 (quindi vero). infatti nelle reference trovi:
This is because C++ evaluates the statement if (x=10) as follows: 10 is assigned to x (remember that the single equal sign is the (assignment operator)), so x now contains 10. Then the 'if' conditional evaluates 10, which always evaluates to TRUE, since any non-zero number evaluates to TRUE. Consequently, if (x = 10) will always evaluate to TRUE, which is not the desired result when using an 'if' statement. Additionally, the variable x will be set to 10, which is also not a desired action
ORSO2001:
l'IDE di arduino (passatemi l'affermazione) non è in grado di verificare se un confronto è fatto tra, o restituisce realmente, un bool; il controllo viene fatto sul valore di ritorno che può essere 0 (quindi falso) o diverso da 0 (quindi vero). infatti nelle reference trovi:
in effetti non serve e non è nemmeno desiderato di controllare che sia un boolean
in C "storico" il tipo bool non esisteva e le cose giravano lo stesso senza farsi tante menate...
ho l'impressione che sia in corso una guerra di religione, sull'uso dei boolean
io sono e continuero' ad essere ateo.......
Standardoil:
in effetti non serve e non è nemmeno desiderato di controllare che sia un boolean
in C "storico" il tipo bool non esisteva e le cose giravano lo stesso senza farsi tante menate...
ho l'impressione che sia in corso una guerra di religione, sull'uso dei boolean
io sono e continuero' ad essere ateo.......
D'accordo con te @standard, però in Arduino .ino si programma in C++ e non C. Dal C++ il "tipo" bool
E sai quante menate hanno aggiunto al C++ (alcune okay, ma alcune sono da spaccarsi il cervello, parere mio)
però sono convinto, senza andare a controllare, che anche in C++ false è sempre zero, true sempre 1 e qualunque cosa diverso da 0 fa vero logico
siamo sempe li: già è diffcile programmare, se dobbiamo anche farci le menate e aggiongere controlli e macro e giri di valzer non andiamo a casa più, specialmente i novizi
serve di imparare a "sgrassare" il proprio programma, passo propedeutico per "sgrassare" anche il proprio modo di pensare, altrimenti si cade sotto al peso di troppe menate
io per esempio non ho ancora capito come sia stato pensato di aggiungere il modificatore "const"
siamo partiti da un linguaggio che dava la piena fiducia al programmatore, dove per definizione il programmatore aveva ragione e il linguaggio si adeguava, si presumeva sempre che il programmatore sapesse cosa faceva
ad uno dove addirittura si può "vietare" al programmatore di fare alcune azioni
ma quando mai? ma che storia è?
perchè? magari perchè i programmatori sono sempre più scrausi? certo che invece di farli imparare metterli in una sandbox dove non possono fare danni non è la soluzione
anche quella supermenata di mettere il tipo della variabile come prefisso del nome, che adesso va per la maggiore
ostia... lo saprò bene di che tipo è la variabile che sto usando, lo sto facendo IO il programma
e se non sono capace non devo fare il programmatore in una sandbox, devo andare a studiare.........
se riconoscere i propri errori è il primo passo per imparare ad evitarli in futuro
se è vero questo, impedire gli errori è il primo passo per non imparare e poi trovarsene a bizzeffe alla prima volta che le "barriere cadono"
vabbe' basta.........
