Newsgroup: it.comp.lang.delphi
Titolo: NULL in BOOLEAN

Vi posto una domanda che un amico mi ha chiesto di farvi...
"Come posso assegnare NULL ad una variabile globale di tipo BOOLEAN
e controllare in seguito se questa sia NULL o meno."
Grazie a tutti.

 e controllare in seguito se questa sia NULL o meno."
Non credo si possa. Una variabile boolean ha solo due stati: true o false.
Comunque in delphi esiste nil e non null. Inoltre in delphi nil e' una
costante di tipo puntatore, quindi la puoi usare solo coi puntatori.
Mi sa che devi trovare altre soluzioni :-)


wrote:

Quasi tutto giusto :) nel senso che il null in realtà esiste.
Una soluzione *potrebbe* quella di usare un LongBool -- o un wordbool
-.
Il LongBool è true se è <> 0 ma si potrebbe gestire in modo atipico. 
Oppure, decisamente meno macchinoso,  una variant, che, appunto,
gestisce i null.
Massimo.
-----------
Ore 18.30: premo invio.

> Quasi tutto giusto :) nel senso che il null in realtà esiste.
Pardon, non ne ero a conoscenza :-)

 Comunque in delphi esiste nil e non null. 
Vedi sopra. Esiste anche Null.
-- 
Posted from  [80.105.34.80] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 wrote in message
hXFu7.14273$0Y2.2...@news.infostrada.it...


Penso che questa sia una buona soluzione ma in termini di pesantezza credo
che sia sempre meglio usare il semplice bit (Boolean).
Ti prego di correggermi se sbaglio!!!!!

innaturali e genererebbero codifiche "mostruose".
Sicuramente il tipo va ridefinito e quindi non si puo' usare
boolean, ma ci possono essere, per esempio, DBMS che
definiscono il valore NULL per i campi booleani che non sono
assegnati (vedi Paradox e molti altri).  In questo caso,
puo' essere conveniente gestirli con un tipo Variant, capace
di assumere sia i valori canonici della logica assertiva
true/false, sia il valore null.
-- 
Andrea Laforgia - walkietalkie(at)
libero.it

 Ti prego di correggermi se sbaglio!!!!!
Sbagli.
Il boolean non viene comunque implementato come un singolo bit
perché sarebbe semplicemente ingestibile su un processore a 32 bit.
Per quanto snello deve usarne almeno 8 ed č comunque tutto da
dimostrare che l'accesso di una variabile da 8 o 16 bit sia piů
rapido, o comunque sensibilmente piů rapido, di una da 32 bit.
Con le CPU e le memorie (RAM o di massa) che ci sono in giro
non sono queste le cose "pesanti".
--
Virgilio Lattanzi       HARPAX srl
Tel: +39 733 816872     via Fontanella, 38
Fax: +39 733 819133     62012 Civitanova Marche MC
WWW: 
www.harpax.com
     ITALY

 wrote in message
3bc45e22...@news.tin.it...


C'è però da dire che il null non è una alternativa a true/false:
Nessuno ha detto questo.
Ma se e' questo che si vuole ottenere, allora il variant risolve il problema.
p.s.: quota sotto il testo a cui rispondi e riporta solo lo stretto
      indispensabile.



Crearsi una classe che supporti gli stati "true", "false" e
"undefined", come il tipo Boolean di Java:
    TBoolean = class
    private
       FValue: BOOLEAN;
       FIsDefined: BOOLEAN;
       function GetIsDefined: BOOLEAN;
       function GetValue: BOOLEAN;
       procedure SetValue(Value: BOOLEAN);
    protected
    public
       property IsDefined: BOOLEAN read FIsDefined write FIsDefined ;
       property Value: BOOLEAN read GetValue write SetValue;
    published
    end; { TBoolean }
e poi 
procedure TBoolean.SetValue(Value: BOOLEAN);
begin
 
 FValue := Value;
 FIsDefined := true;
 
end;
function TBoolean.GetValue: BOOLEAN;
begin
  if not FIsDefined then
    raise ecc ecc
  else 
    result := FValue;
end;
--
Piero Bonanno
bop...@libero.it
pie...@tiscalinet.it
bpie...@hotmail.com
______________________________________________
"Madame, lei ha tra le gambe uno strumento
che puo' offrire piacere a migliaia di persone,
e tutto quello che sa fare e' grattarlo"
- Sir Thomas Beechan a una violoncellista

end;
E' una soluzione molto carina, ma (per il mio modo di pensare) la
trovo rischiosa: qualche fesso potrebbe scriverci un valore di tipo
stringa, intero, valuta o chissacche' (per disattenzione, che e' la
madre di tutti gli errori di programmazione :) )
Ciao


"undefined", come il tipo Boolean di Java:
Gia', peccato che, a mio avviso, sia inutilizzabile una
classe del genere in Delphi.
Tieni presente che ogni volta che utilizzi un boolean lo
devi creare (con il costruttore) e distruggerlo (con Free).
In OP non esiste l'allocazione statica (come in Java).


classe del genere in Delphi.
Lo so, pero' e' l'unica implementazione "sicura". Fondamentalmente
odio i variant


odio i variant
Sicche' 
B := True; 
diventerebbe:
B := TBoolean.Create;
try
  B.SetValue(true);
finally
  B.Free;
end;
Mah... contenti voi..


 Mah... contenti voi..
In effetti l'allocazione statica sarebbe una bella cosa.
Che tu sappia in BCB si puo' usare questo meccanismo o si e' comunque
vincolati al meccanismo di allocazione dinamica della vcl?
Saluti
Paolo Arosio

 wrote in message
3bc2458d...@news.tin.it...


dell'esistenza di qualche falla nella struttura di un algoritmo.
Non sono d'accordo: nel campo dei database i valori null spesso sono
usati e a volte indispensabili, anche booleani,  e non significa che
il codice abbia delle falle.
Un esempio: un campo boolean che DEVE essere assegnato ma di default
NON deve avere in valore di default onde essere sicuri che l'utente lo
assegni. Tanto è vero che i checkbox hanno come opzione in un terzo
valore, undefined, oltre a checked e unchecked.
Che poi, da un punto di vista matematico-filosofico, questo sia
errato, francamente, poco mi importa.


vincolati al meccanismo di allocazione dinamica della vcl?
No, in BCB non e' possibile usare l'allocazione statica per
tutti gli oggetti appartenenti alla VCL (devono
necessariamente essere allocati dinamicamente), mentre per
tutti gli altri oggetti si segue la normale semantica del
C++.


implementare il "terzo valore" booleano?
Nel caso dei DB, ci puo' essere il valore "indefinito" per
variabili di qualsiasi tipo built-in.  E' per questo che
vengono introdotti i Variant.  Il booleano di un campo del
DB non e' un reale booleano, e' un campo che puo' conservare
tre valori diversi (true, false, indefinito).


errato, francamente, poco mi importa.
Esatto.  
In programmazione si bada a degli aspetti pratici.
Ricalcare, nella pratica, un concetto matematico puo' non
essere la via giusta di procedere.
Molto spesso e' cosi'.


Vi posto una domanda che un amico mi ha chiesto di farvi...

Io proverei qualcosa del genere:
type
  TWeirdBool = (true, false, null);
var
  wBool : TWeirdBool;
begin
  wBool := null;
  //
  wBool := true;
  // 
  if WBool = true then ...
ecc...
-- 
(* So I dub thee unforgiven *)
{Sostenete la lega per la soppressione dello sceriffo nano e dei suoi seguaci}

end;
Tengo a precisare che con quello che hai scritto tu si potrebbe
arrivare a
B:='pippo';
Ogni soluzione ha pregi e difetti. Io userei la classe sono in qualche
contenitore, e.g. una classe business o qualcosa del tipo TField, che
mi eviti la noia di creare e distruggere.
Non userei mai i variant, cmq.
Saluti


 B:='pippo';
Non stiamo facendo a gara a chi e' piu' bravo.
Ammetti che la soluzione da te proposta e' troppo macchinosa, per 
essere utilizzata nella pratica, con un linguaggio come OOP.
Se fosse C++ ci potrei anche stare.
I Variant sono anche antipatici, ma in questo caso, sono una 
delle poche soluzioni (compatibili coi DB) che si puo' utilizzare
facilmente.


 distrutto.
Era un esempio, ovviamente...


 Molto spesso e' cosi'.
Faccio qualche puntualizzazione, ma d'altronde i ng esistono apposta per
discutere e scambiarsi opinioni.
Massimo, il codice e i database sono cose diverse, e non possono essere
trattati come fossero la stessa cosa addirittura nello stesso contesto come
fai tu. I database sono strutture organizzate di dati statici, il codice è
una formalizzazione algoritmica delle procedure di accesso in
lettura/scrittura a quelle strutture.
E dunque in una tabella, che nasce come struttura logica prima e
indipendentemente dalla effettiva esistenza dei dati (possono infatti
esistere tabelle vuote), è importante stabilire innanzitutto se un dato è
definito o meno: nel primo caso viene inserito in tabella, nel secondo viene
sostituito dal valore null.
Nel caso di una tabella contenente una colonna di valori booleani, il "null"
corrisponde al valore "false" della istanza sulla definizione del dato. In
pascal-like:
if (IsKnown(InputVal) = true) then       // primo confronto booleano
begin
  if (InputVal = true) then                     // secondo confronto
booleano
    MyTable.BoolColumn.Add(true)
  else
    MyTable.BoolColumn.Add(false)
end
else
  MyTable.BoolColumn.Add(null);
Allora il valore null non è il "terzo valore" booleano neanche nei database,
ma piuttosto un valore del comune tipo booleano a due stati relativo alla
istanza preliminare sulla definizione del contenuto di una cella di una
tabella. Il valore di una cella o è definito oppure è non definito: non è
data una terza possibilità; se è definito e contiene un valore booleano
questo può essere
o vero o falso: non è data una terza possibilità.
Come si vede, una volta che dai dati statici si scende alla loro gestione
per mezzo di un qualche algoritmo, il "terzo valore" booleano non solo è un
contro-senso, ma non ha neanche più ragione di esistere.
Andrea, la matematica, la filosofia, la logica ecc, non sono altro che
descrizioni formalmente rigorose della realtà, e non discipline astratte
delle quali, qualche volta, si può anche fare a meno. In programmazione se
non si ricalca qualche concetto matematico si è certamente sulla via
sbagliata. Se una macchina non viene programmata in modo rigoroso esibisce
un
comportamento diverso da quello atteso o voluto, e la mancanza di rigore
logico nel flusso di un algoritmo ha, in programmazione, un nome ben
preciso: bug.
L'importanza (addirittura fondativa) della matematica e della logica nella
programmazione sono troppo evidenti per essere sottolineate da me. Basti
dire che la moderna gestione dei database relazionali è completamente basata
sulla teoria matematica degli insiemi.
Voglio però ricordare che i moderni linguaggi imperativi (pascal, basic, c,
ecc.)
non sarebbero potuti esistere senza le speculazioni, ad esempio, di Socrate,
di Cartesio
o di Kant.
Ti sei mai chiesto perchè il pascal si chiama così?


preciso: bug.
Sei un po' indietro: mi ricorda tanto il neopositivismo logico, mi
piaceva al liceo (come pure il futurismo), ora lo trovo un po'
vecchio, diciamo pure surreale. 
Sei in grado di dare una descrizione formale della realta'? Beato te:
mi sembra che i grandi fisici teorici siano un po' piu' confusi.
Però tirare in ballo certi discorsi per un booleano mi sembra
eccessivo :-)


si è certamente sulla via sbagliata. 
Sbagliato, ci sono molti concetti matematici che e'
sbagliato ricalcare in programmazione.
Se vuoi un riferimento interessante, leggi l'articolo di
Carlo Pescio sull'uso e abuso dell'ereditarieta' nei
progetti reali.  Ci sono moltissimi casi in cui, pensare di
seguire un modello matematico in programmazione, puo'
condurre a degli errori di progettazione mostruosi.


facilmente.
Sono costretto tuttora a usare i componenti ADO e quindi gli
OleVariant. Mi sto schifando di tutti i problemi che mi creano, e mi
chiedo in quale situazione qualcuno puo' avere bisogno di una
variabile che puo' contenere numeri, stringhe, booleani. La
possibilita' del Null mi sembra un vantaggio trascurabile.
Ciao


variant.
I variant sono bruttissimi, lo ammetto, proprio perche'
annullano quello che secondo me e' un grande vantaggio dei
linguaggi come il Pascal e il C++, ovvero la forte
tipizzazione (meno vero per il puro C), che ti fa
risparmiare lunghe sudate alla caccia di bug.
In qualche caso risultano utili, ma bisogna sapere bene che
cosa si sta facendo e gran parte dei programmatori non lo sa
;))
-- 
The Follet