Newsgroup: it.comp.lang.c++
Titolo: Curiosità sul boolean

Avevo già scritto molto tempo fa una domanda come questa, ma sinceramente la
risposta non l'avevo capito molto, e, visto che a scuola ho rifatto
l'argomento mi è tornata.
In C++ non esiste il boolean come tipo. Al suo posto si utilizzano i numeri,
quindi ogni numero diverso da 0 è true, 0 è false. Questo è molto semplice.
Ma quello che mi sorge strano è il perchè di questa necessità. Ossia, perchè
non implementare anche il tipo booleano? In Visual Basic si va molto bene,
non capiusco il perchè. Tra l'altro (piccolezze per carità!) una variabile
boolean dovrebbe occupare meno di una int.
Spesso poi ho utilizzato una dichiarazione come questa:
#define TRUE = !0
#define FALSE = 0
In questo caso c'è sempre spreco di memoria o sbaglio? Non che mi crei
problemi il sistema, ma volevo sapere se esiste un motivo particolare a cui
non ho pensato per cui esiste questa sostituzione, solo una curiosità.
Grazie e ciao a tutti.
Ramses

 boolean dovrebbe occupare meno di una int.
Direi di no... credo che i compilatori quando ottimizzano il codice per i
moderni microprocessori li trasformerebbero comunque in interi a 16 o 32
bit... anche se non lo posso provare con certezza...bisognerebbe lanciare un
debugger e vedere cosa fa visualbasic e gli altri linguaggi, come il pascal
che utilizzano i boolean. Credo che si faccia questo per aumentare le
prestazioni.
In effetti a volte ho notato che le prestazioni di alcuni miei programmi
aumentano evitando di usare interi a 8 bit, preferendo quelli a 16 o
addirittura a 32, anche se risparmierei memoria.
Comunque con C/C++ si lavora in modo trasparente anche se formalmente non
esistono, come hai detto anche tu.

In questo caso c'è sempre spreco di memoria o sbaglio?
E perché devi usare una dichiarazione come quella? non puoi usare true
e false?
-- 
                    Marco Barisione (ICQ 84277092)
Se sei interessato alla creazione di un newsgroup generico in cui si
possa parlare di quei linguaggi di programmazione senza un gruppo
apposito vota per it.comp.lang su it.news.votazioni.

 e false?
oltretutto la define è anche sbagliata... :-)
Maurizio
-- 
Maurizio Sambati
Skice Software
E-mail: 
gsm...@inwind.it
--------------------------

In questo caso c'è sempre spreco di memoria o sbaglio?
Il tipo 'bool' penso che dovrebbe occupare un byte su tutte le
piattaforme, sarebbe assurdo sprecarne di più visto che viene
utilizzato un solo bit, ma visto che non é possibile per una macchina
indirizzare un singolo bit lo "spreco" di un byte é un male
necessario.
Il Ghenio
---------
These are my parting words to you:
those who give up are doomed!

 necessario.
Esatto.
Il bool occupa la stessa quantità di memoria della più piccola entità
indirizzabile direttamente dalla macchina, e dovrebbe essere la stessa che
per i char.
Non sono sicuro che il discorso del byte valga proprio per tutte le
piattaforme hardware.
Ciao,
Antonio

Che voi sappiate, se dichiaro 8 variabili bool di fila i compilatori riescono
a ottimizzarle usando un solo byte?
--
Stefano

 a ottimizzarle usando un solo byte?
Cosa sono 8 bool di fila? Al limite si potrebbero ottimizzare gli array 
di bool (come fa il Pascal)...
-- 
Luc.

...

lo fa anche l'STL. Se guardi il paragrafo 23.2.5 dello standard si
intitola proprio "Class vector<bool>" e inizia cosě:
23.2.5.1
: To optimize space allocation, a specialization of vector for
bool elements is provided: ...

Stefano wrote:

Se dichiari 8 variabili di fila, non credo.
ma se usi un std::vector<bool> (o, se te ne servono 
un numero fisso, un bitset<8>) i valori sono
memorizzati in maniera ottimale
Fabio
-- 
Posted from 
flopiano.mm.eutelsat.org
 [194.214.173.28] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 #define FALSE = 0
Questo è C. In C++ non serve dato che true e false (minuscole) fanno
parte del linguaggio.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 a ottimizzarle usando un solo byte?
No. E non è detto che sarebbe un'ottimizzazione. Salveresti spazio ma
gli accessi invece che con una sola istruzione ne richiederebbero minimo
2.
Però se dichiari un vector di bool allora saranno "impaccati".


 boolean dovrebbe occupare meno di una int.
che mi ricorda una situazione per cui il valore booleano restituito sia un int
è
una funzione..
bool f()
{
   return (3<4)
}
in questo caso ritornerà un int di tipo bool "vero" perchè 3 è inferiore a 4.
adesso mi ritorna in mente una cosa, nelle cpu un registro dovrebbe contenere
sempre
il valore 0, cioè falso, e nessuno lo può toccare,
questo perchè l'uso di questo valore viene ripetuto per moltissime volte.
ciao duido 
-- 
Posted from  [62.98.92.80] 


a ottimizzarle usando un solo byte?
Vado ad intuito. Penso di no, perché non mi sembra un'ottimizzazione
facile per il compilatore. Il c++ prevede nella sua lib.standard
vector<bool>, una specializzazione dei vector che usa proprio i bit
come unità di memorizzazione.
Decisamente da usare, se non si vuole sprecare spazio.


 necessario.
non e' detto. Alcune piattaforme potrebbero allinearlo alla dimensione 
della parola per questioni di efficienza.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 memorizzati in maniera ottimale
Lo immaginavo. Ora mi viene in mente un'altra cosa: se vector<T> è una
template e può essere istanziata con "qualsiasi" T, come fa a capire, nel caso
si usasse vector<bool>, di cambiare l'implementazione normale e ottimizzare
per i bool considerandoli come dei bit?
--
Stefano

 Errore. Non esiste nel C,
[snip]
A dire il vero c'e` anche nel C99.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
"L'ottimista pensa che questo sia il migliore dei mondi possibili. 
 Il pessimista sa che e` vero" -- J. Robert Oppenheimer

 per i bool considerandoli come dei bit?
Lo standard specifica che std::vector<bool> e' una specializzazione di
std::vector, che si comporta in maniera differente. Questa e'
considerata da molti una scelta infelice del comitato di
standardizzazione.
Ciao,
Nicola

standardizzazione.
Perché? Cosa dice lo standard esattamente?


 questo perchč l'uso di questo valore viene ripetuto per moltissime volte.
Non su tutti i processori, sui vari mips e affini invece il registro 00 e' 
quello di cui parli.
-- 
FUSION (fyu zh & n) n: 
1) the Act or Process of Fusing or Melting Together... 
2) the State of being Fused... 
3) to Join or become Combined...

 Perché? Cosa dice lo standard esattamente?
"
To optimize space allocation, a specialization of vector for bool elements
is provided:
namespace std {
template <class Allocator> class vector<bool, Allocator> { .... }
"
Se C supporta l'operatore[]  e' considerato un contenitore di tipi T se puoi
fare
T* pT  &c[0];   // Assignment requirement
in realta' se vedi la specializazione di vector<bool> l'operatore []
non torna un T ma un proxy "reference".
E lo standard definisce:
"reference is a class that simulates the behavior of references of a single
bit in vector<bool>".
Quindi puoi scrivere vector<bool> ma non e' un container.
Quelli dello standard scelsero di sviluppare vector<bool> per dimostrare
come la STL dovesse supportare i container i quali elementi fossero
accedibili
via un proxy. Meyers dice che l'esperimento falli' (ma non dice esattamente
perche').
La cosa che rimane e' che vector<bool> non ha tutti i requisiti
per essere considerato container.
-- 
Posted from 
dell-01.mm.eutelsat.org
 [194.214.173.17] 


per essere considerato container.
A me pare che soddisfi tutti i "container requirements" elencati in
tabella 65 dello standard.
--
Posted from 
dell-01.mm.eutelsat.org
 [194.214.173.17]
via Mailgate.ORG Server - 
http://www.Mailgate.ORG
--


 tabella 65 dello standard.
La seconda riga della tabella dice:   X::reference lvalue of T
e nel caso di vector<bool> lo standard dice che reference
in realta' e' un proxy.
Ciao
Gaetano.


 in realta' e' un proxy.
Infatti. Ma un proxy che ammette l'assegnamento di un bool puň essere
considerato un lvalue of T in quel senso. O almeno direi che questo č
quello che intendevano nello standard (quale altro tipo puň essere un
lvalue of T escludendo T&? Se hanno detto "lvalue of T" evidentemente
intendevano qualcosa di piů generico rispetto a dire "T&").



A questo punto si  dovrebbe chiedere a Meyers dove sta scritto.
Lo faccio io o lo fai tu ?
es...@eristeia.com


Lo faccio io o lo fai tu ?
Anche se ho già corrisposto con lui in passato è meglio che lo fai tu.
Anche perchè non ho capito bene a quale dei suoi scritti ti riferisci.
Ricorda di presentargli il fatto che l'uso della frase "lvalue of T"
invece che semplicemente "T&" dovrebbe sottintendere che esiste almeno
un altro modo per avere un "lvalue of T" e che non vedo quale altro modo
se non una classe con metodi operator T() e operator=(T) o equivalenti.



Prima che io scriva ti volevo far notare che la seconda riga della tabella
65 dice:
expression -> X::reference
return type -> lvalue of T
complexity -> compile time.
Il requirement di complessita' mi sa che viene violato dal vector<bool>.
Ciao
Gaetano



Per nulla. std::vector<bool>::reference si risolve a compile time (č di
fatto un typedef e tutti i typedef si risolvono a compile time).



std::vector<bool>::reference non e' un typedef  ma la seguente classe:
class reference {
friend class vector;
reference();
public:
~reference();
operator bool() const;
reference& operator(const bool x);
reference& operator(const reference& x);
void flip(); // flips the bit
};
Ciao
Gaetano.


};
Ancor più vero quindi che il nome si risolve a compile time! Dov'è il
problema?



l'operator [] e' cosi' definito.
reference vector<Bool>::operator[](size_type n);
vector<bool> myVector;
.....
bool aBool  myVector[0];
myVector[0] torna un
vector<bool>::reference e viene assegnato aBoll
tramite la chiamata dell'operator bool della classe reference.
Penso sia questo che viola il requirement.
Attendo di sapere che mi dice Meyers.



Ho scritto a Meyers:
"In your book Effective STL in the Item 18 "Avoiding using vector<bool>"
you wrote that if "c" is a container of  T and support operator[]
the expression
T *p  &c[0];
must compile.
I was looking for this requirement in the section 23.1 of the C++ Standard
but I didn't find this requirement.
The second requirement of the table 65 say:
expression ->   X::reference
return type -> lvalue of T
complexity -> compile time.
do you mean that these requirement is not provided by vector<bool> ? "
e mi ha risposto:
"I believe that this is clarified in the ESTL on-line errata, but I can't
check right now, because I have no web access.  To answer your question,
the problem is not that
  vector<bool> v;
  ...
  bool *pb  &v[0];
won't compile, it's that this additional statement,
  *pb  true;
can't possibly modify v[0].
Scott"


can't possibly modify v[0].
Il che è vero. Ma ci stiamo dimenticando che l'accesso al contenuto di
un container non lo si fa tramite reference ordinarie o puntatori
ordinari. Lo si fa tramite V::reference e V::iterator. Dire che prendere
l'indirizzo di un V::reference deve dare un puntatore all'oggetto
sarebbe come dire che un iterator deve essere un puntatore. Quindi solo
vector di tipo non bool sarebbe un container. Gli iterator di list, set
e altri container non sono puntatori ne possono esserlo.
In altre parole: usando operator[] su un container che lo supporta da
accesso diretto ad un oggetto, ma non è assolutamente detto che dia
accesso al suo indirizzo. Prendere l'indirizzo di ciò che ritorna
operator[] si può fare, ma è l'indirizzo di un C<T>::reference e non di
un T. In generale NON si lavora per puntatori con i container. Si lavora
per iterator. Direi che C<T>::iterator sta a T* come C<T> sta a T[]. E
come C<T>::reference sta a T&. Se usi C<T> allora NON DEVI usare ne T&
ne T* ma piuttosto C<T>::reference e C<T>::iterator.
E notando che non sono sicuro che sia garantito che operator& applicato
a C<T>::reference ritorni un C<T>::iterator (o che operator* sul secondo
ritorni il primo, cose che sarebbe invece interessante aggiungere nello
standard).


 ritorna un reference. Semmai ci si potrebbe aspettare che compili:
Ovviamente nel post originale dopo = c'era & che mailgate se magnato.
Ciao
Gaetano. 
-- 
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15] 


 parte del linguaggio.
Beh, a parte il fatto che ho messo un uguale che noncentrava, cmq grazie.
Grazie a tutti.
Ramses

Come si gestisce la mancanza del tipo booleano in C++?
Che tristezza. Il tipo bool non brilla certo ... pero' anche dire
che non c'e' mi sembra eccessivo. Fra l'altro non sapevo che si
trattasse di una intoduzione recente nel C++...
Il bool (che supporta conversioni implicite) a oggi secondo me crea
un po' confusione. Dovendo pero' mantenere la compatibilita' con
il C onestamente non credo che ci fossero soluzioni eleganti al
problema ...
Andrea

 
Beh, non c'è molto da capire.
Direi che, a questo punto, faresti un buon servizio agli attuali e futuri
studenti, se segnalassi al docente l'inesattezza riportata dal libro.
Max

 Questo per via di come il OS alloca la memoria?
No. Per via di come è definito il linguaggio.


 trattasse di una intoduzione recente nel C++...
Dipende da cosa consideri recente. Certo non c'era nel C++ prestandard.
E forse neppure nei primissimi draft. Ma parliama comunque di una
manciata di anni. I libri scolastici sono più o meno ristampati ogni
anno. Almeno un addendum lo avrebbero potuto mettere. O meglio ancora
una nuova edizione.
Per non parlare della serietà del professore e della sua capacità di
restare aggiornato!


 studenti, se segnalassi al docente l'inesattezza riportata dal libro.
Valutando bene il professore.
Segnalando la cosa di fatto sottintendi che il professore non conosce
quello che insegna e non è capace di tenersi aggiornato ... su "novità"
vecchie di una manciata di anni.
In altre parole gli dai del coglione.
Quindi valuta bene quanto coglione è. Se lo è abbastanza da non
accorgersi che gli stai dando del coglione allora Ok. Ma sperare che sia
abbastanza intelligente da accettare la critica ... IMO se lo fosse
sarebbe anche più aggiornato!



Potrebbe stampare questo post e farglielo leggere (Ovviamente cuttando il
tuo
intervento sopra :-)  )
INTERNATIONAL STANDARD ISO/IEC 14882
Programming languages - C++
3.9.1 sez 6
Values of type bool are either true or false.42) [Note: there are no signed,
unsigned, short, or
long bool types or values. ] As described below, bool values behave as
integral types. Values of type
bool participate in integral promotions (4.5).
3.9.1. sez 7
Types bool, char, wchar_t, and the signed and unsigned integer types are
collectively called integral
types.43) A synonym for integral type is integer type. The representations
of integral types shall define values
by use of a pure binary numeration system.44) [Example: this International
Standard permits 2's complement,
1's complement and signed magnitude representations for integral types. ]


 
 Facci sapere il titolo del libro, casa editrice ed autore,
 versione e anno di stampa.
 Facci sapere in oltre la scuola che frequenti (indirizzo).
 Il nome del sig Preside e del Prof.
 
 Io un'idea l'avrei,
ad esempio invitare Editore, Scrittore, Prof, Preside
alla pizzata del NG, o ad esempio un bel letterone
al ministro della publica istruzione e/o al provveditorato
agli studi.


 


  Gaetano.
Ramses

 Max
Grazie, Ramses.

 no. Chiaramente se è un commento non è da eseguire...
Il classico tipo di professore con il quale io mi scontravo. In senso
letterale. Stile dichiarare pubblicamente che non conosce il significato
di un remark e seguente protesta formale con il preside con richiesta di
destituirlo. Di solito finiva che i due voti tolti nel compito specifico
mi ritornavano. Poi sparivano definitivamente da tutti i compiti
successivi (salvo quando erano assolutamente perfetti e mi pigliavo 8
per lo svolgimento e 6 per brutta grafia e disordine con media 7).
Ma io sono (e soprattutto ero) l'antitesi della diplomazia. Tu fai bene
a stare schiscio e rispondere quello che lui vuole che tu risponda.


 Andrea Ferro
Grazie e ciao ancora.
Ramses

 Andrea Ferro
Ramses

 Io faccio il liceo scientifico ad indirizzo tecnologico.
Mi sembra poca come informazione.
c


trattasse di una intoduzione recente nel C++...
Può darsi che la sua introduzione nello standard sia relativamente
recente(ma ha sicuramente già alcuni anni), ma che alcuni compilatori
lo supportassero già da prima.
Il Ghenio
---------
These are my parting words to you:
those who give up are doomed!

Per curiosita' ho chiesto su comp.std.c++ quando e' stato introdotto il
tipo bool. Tra gli altri Andrew Koenig ha risposto: "The first working
paper in which it appears was the one for the March 1994 meeting."
Direi che il suddetto prof. e' rimasto un po' indietro...
Ciao,
Nicola

lo supportassero già da prima.
A quanto ha riportato Nicola sembra che bool abbia cominciato a
fare le prime apparizioni nel 1994.
Andrea

 continuato a pensare che il bool non esiste in C++.
Ragione sul fatto che la materia è controversa? No di certo. Non è per
nulla controversa. Il C++ poteva essere considerato controverso prima
che uscisse lo standard. Alcuni aspetti dello standard possono essere
controversi dato che sono poco chiari o dicono cose opposte fra loro. Ma
la presenza di bool nel linguaggio non è controversa per nulla.


 la presenza di bool nel linguaggio non è controversa per nulla.
Mah, forse in questo posso anche essere daccordo con lui. Ossia, sicuramente
abbiamo appurato che il bool esiste al momento (e ciò risulta chiaro), ma
che il campo sia alquanto caotico, sono daccordo con lui. Infatti io, da
quando cerco di imparare il C++ ho potuto notare quanto sia difficile avere
certezze.
Grazie di tutto.
Ramses

 Nicola
Cia a te.
Ramses

 wrote in message
news:_bcP7.240588$sq5.11...@news.infostrada.it...

Mumble. Forse una cosa che non sai (ma che lui in teoria non dovrebbe
permettersi di non sapere e che credevo fosse chiaro anche nel messaggio
precedente) è che il C++ ha subito un processo di standardizzazione. Il
documento che definisce il linguaggio è stato pubblicato nel '98. Da
quel momento in poi ogni e qualunque controversia va risolta sulla base
di quel documento. Restano aperte solo eventuali controversie sul
documento in se (dove è poco chiaro o dove è contradditorio, per
esempio). Per queste esiste la possibilità di sottoporre la questione al
comitato per chiarimenti.
L'unica vera confusione è dovuta al fatto che:
1) esistono ancora un sacco di testi che sono stati scritti prima della
standardizzazione. Chiunque usi questi testi come riferimento commette
un grave errore e la confusione che ne deriva è sua esclusiva
responsabilità.
2) esistono testi successivi allo standard ... ma che riportano
informazioni errate (Shcildt è un esempio) o che non tengono conto dello
standard ma bensì dello stato del linguaggio quando era ancora in
evoluzione (il tuo libro di testo che almeno in parte riporta notizie su
l C++ che erano vere nel 93 quando lo standard non esisteva ed
esistevano solo tanti compilatori ognuno leggermente diverso dagli altri
ma che non lo sono di certo più oggi). Chi usa questi testi è scusato
solo se è un malcapitato che li compera senza sapere bene come stanno le
cose. Ma la responsabilità degli autori di simili testi è limitata
davanti a scelte fatte da docenti che dovrebbero PRIMA conoscere
l'argomento e POI scegliere i testi che lo spiegano meglio.
3) esistono ancora molte situazioni in cui si usano compilatori che sono
stati sviluppati prima che uscisse lo standard. Ovviamente questo va
evitato ove possibile e accettato ove necessario ma SOLO essendo
coscenti che quello che il compilatore compila non è, tecnicamente, C++
e che pertanto è responsabilità del programmatore e non del compilatore
sapere quali parti del linguaggio sono correttamente implementate e
quali non lo sono.
4) di fatto anche i compilatori post-standard non sono ancora
"conforming". In altre parole anche se sono compilatori recenti non
implementano ancora del tutto lo standard. Quindi anche DOPO aver
aggiornato il compilatore è ANCORA necessario che il programmatore sia
cosciente di cosa sta facendo.
Dici che è difficile avere certezze. In realtà salvo alcuni aspetti in
cui lo standard non è del tutto esplicito (e bool non è certo uno di
questi) è facilissimo avere delle certezze. Basta leggere l'unico testo
che fa testo (il che non è solo un gioco di parole ma la realtà). Ovvero
il documento di standardizzazione.
Non certo come "testo didattico" (credo di essere l'unico che ha
studiato il linguaggio pre-standard leggendo l'ARM e il linguaggio
standard e la STL leggendo un draft dello standard!). Ma certamente come
testo di riferimento. Per i testi didattici ... vedi FAQ e discussioni
recenti.


 secondo me, quasi 4 anni senza modifiche sono vweramente troppi.
Certissimo. Sopratutto un libro di informatica che parla di un
linguaggio la cui definizione č stata completato proprio nel 1998 NON
PUO' non essere aggiornato in data successiva!
Perň fino a che ci sono scuole e professori che lo adottano come libro
di testo non č che editore e autori siano molto incentivati!


 di testo non č che editore e autori siano molto incentivati!
Fa colpo il confronto con altri argomenti, in cui i libri diventano
obsoleti in sei mesi, e si assiste alla continua uscita di nuove
edizioni. Java non e' che un esempio...
Ciao,
Nicola

si presume che lavorino in ambiente competitivo).
Programmerà per windows dove BOOL è un int e non un bool così non si
sarà accorto negli ultimi anni che il tipo bool esiste.
-- 
                    Marco Barisione (ICQ 84277092)
Se sei interessato alla creazione di un newsgroup generico in cui si
possa parlare di quei linguaggi di programmazione senza un gruppo
apposito vota per it.comp.lang su it.news.votazioni.

 sarà accorto negli ultimi anni che il tipo bool esiste.
In altre parole è un professionista convinto che windows.h sia un header
del c++ standard.
Di bene in meglio!
