Newsgroup: it.comp.lang.visual-basic
Titolo: Null,Nothing,Empty

 ma, più che 'non giustificata' mi sembra semplicemente 'non usata'
Ok, ma se non venisse mai assegnata, settata, etc.? davvero inutile no? Non
giustificata, appunto.
Poi bisognerebbe (ormai siamo abbondantemente OT, farò danni se mi dilungo
un pelo?) discutere sull'interpretazione di Null o Nothing.
Io non credo al nulla, come non credo all'infinito.
Nel senso che i due concetti non stanno nella mia testa, dopo un po' che ci
penso fuma.
Una variabile non definita, semplicemente non esiste.
Una variabile definita, IMHO, esiste eccome e quindi qualsiasi contenuto
abbia (0, "", Null, Nothing, senza voler fare paragoni per il libero elenco)
questo rappresenta qualcosa, indefinibile e/o non misurabile, ma
assolutamente presente in quanto la sua "scatola" esiste. Dentro la scatola
c'è "qualcosa" che qualcuno ha definito Null o Nothing, ma che nessenu,
nemmeno lui, potrà mai abbinare al "nulla". Se così fosse, risponderei
"allora perchè hai dovuto definire Null e Nothing?".
In questo senso il mio scherzoso "giustificata" sta a indicare che una
variabile (o un oggetto) contiene qualcosa (compreso Null o Nothing), mentre
non è giustificata se non le è stato esplicitamente assegnato un valore,
cioè qualcosa (sempre compreso Null e Nothing).
Che poi il qualcuno di prima, per sua spudorata comodità (e, IMHO, la
scomodità degli altri), abbia deciso che la definizione di una variabile
tipizzata le faccia contestualmente assumere un "valore" (o "qualcosa") è un
altro discorso. Comprensibile e quasi obbligato, direi. Nemmeno lui poteva
mettere il nulla in una variabile, solo perchè non esiste e quindi non può
comprarlo.

 variabili che usa è l'unico a non essere giustificato :)
il che, ça va sans dire, lo svalorizza.

 variabili che usa è l'unico a non essere giustificato :)
Certo.
Mi chiedo: Se qualcuno ha inventato Option Explicit che s'arrabbia quando
fai riferimento a una variabile non definita, perchè (da che c'era) non ha
fatto anche il contrario: "Caro amico, hai definito queste variabili e poi
non le hai usate nemmeno una volta. Che faccio? Le tengo perchè non hai
finito ed è ora di pranzo o le cancello/commento?".
Future and Permanent Copyright by Lupo oppure c'è e Lupo dorme come un ghiro
stanco?

 stanco?
C'č. Non le cancella/commenta, ma te le evidenzia, il che č giŕ tanto.
MZTools, 
http://www.mztools.com/
 fa questo e molto altro;
anche in italiano, per VB5, VB6 e VBA. Free :-))))))
E, sě, hai ragione, poteva mettercelo Bill, giŕ che c'era, insieme
ad un altro paio di cose, ma lasciamo perdere, prima di
scatenare un'altro 3ad mostruoso.
Bye, G.

 scatenare un'altro 3ad mostruoso.
Hai tolto qualche zero dopo quel "paio", vero?!
Giusto, non scateniamo che io son già stato fin troppo dietro la lavagna.
Vado a nanna. 'notte. ;-)

 Vado a nanna. 'notte. ;-)
' n[OT]te :-)
Bye, G.

 faccio io, avrebbe potuto farlo lo sfaticato Bill.
Non credo. Il fatto che restituisca Null non è un caso o pura convenzione.
Sul record i campi, fisicamente, non esistono.
se un record ha 100 campi, in realtà, fisicamente ha memorizzato su disco
solo i campi pieni (anche con 0). Come fai tu, sprechi spazio su disco
(anche se lo puoi fare benissimo, visto che oggi questa ottimizzazione ha
poco senso)
Prova a creare una tabella di 150 campi e fai un ciclo che ti aggiunga
10.000 records vuoti. Vedrai che la dimensione cambia di poco. Poi azzera i
campi e noterai come siano effettivamente stati scritti su disco.
Fabio

 poco senso)
Questa spiegazione mi sta benissimo. Chiara e incontestabile. Grazie.
... un motivo in più per usare (fra me e me) "giustificare".

 campi e noterai come siano effettivamente stati scritti su disco.
hmmm.... me l'ero fatto per testare un programma
l'mdb ha 14 campi txt da 255, 1 memo e 1 contatore.
nel contatore metto j, in tutti gli altri s = Format(j, "000000000").
j e' appunto 0 to 9999.
con i 4 del long e i 9 di ogni txt/memo
secondo il tuo calcolo dovrebbe crescere
(4 + (15 * 9)) * 10k = 1.390.000
se occupasse tutto lo spazio teorico
(anche calcolando i memo solo a 255)
(4+ ( 15*255)) * 10k = 38.290.000
invece da 83.968 byte (vuoto) passa a 4.163.584.
allora come cresce l'emmedibi' ?
ciao, a.


Secondo me la prima che hai detto è quella che fa crescere l'mdb. A parte il
fatto che contandoli mi tornano 16 campi e non 15 :P. Che triplichi la
dimensione ci sta, perché suppongo che oltre al record scriva
anche un bell'ammasso di puntatori, che occupano comunque meno del record
completo in tutta la sua ampiezza. Inoltre, se per caso hai definito il
contatore come chiave primaria nell'mdb c'è anche duplicata la lista
completa delle chiavi, che consiste, per ogni record del file di
'key:puntatore". Poi la prova dovresti farla senza memo. Da quello che
ricordo, i memo sono definiti in strutture a parte, e probabilmente occupano
diverso spazio anche se vuoti.
Di una cosa sono certo: Sul campo se non ci scrivi nulla, su disco non
esiste. E' questa la ragione della restituzione Null. Il campo è definito
nella struttura ma non è mai stato inizializzato. Se scrivi un record
completamente vuoto, sul record su disco ci scrive solo i puntatori alla
struttura della tabella e probabilmente altre fregnacce. Da quello che ho
potuto capire la struttura dell'mdb di Access è una matassa di puntatori e
descrittori vari. Per non parlare del buffer di paginazione. Mi sembra già
se ne parlò tempo fa, ma se apri l'mdb con un editor binario ci trovi pezzi
di documenti word ecc.. Probabilmente i 4MB sono 2 o 3, ma lui si autoalloca
ad una dimensione che immagina possa essere sufficente per le tue esigenze.
Un po come si fa quando si ottimizzano i ReDim degli Array incrementando il
bound ad esempio di 10 in 10 e non ogni volta che si aggiunge 1 elemento.
Fabio

 fatto che contandoli mi tornano 16 campi e non 15 :P
anche a me. esplicito le parentesi di sopra:
    15 * x
        +
    1 * 4 (long)
        =
    16
:P:P
la stazza mi incuriosisce.
in effetti sioccamente (come dicono qui) non avevo calcolcato gli
indizi (sdrucciolo).
questi sono pericolosi indizi (piano) d'invecchiamenti e atrofie...
vb (acronimo di vabbe'), ci si ripensa dopo gli agognati 5 gg di
ferie...
( hanno gia' dato brutto. almeno j si divertira' nelle paludi )
se vuoi divertirti con calc.exe, qui c'e' la struttura.
( primary key, questa sconosciuta :P )
ciao, a.
===========================
TABLE: indirizzi
'------FLD: pcnum (N-LONG ; Size: 4 ; Req.: Falso)
'------FLD: titolo (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: nome (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: cognome (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: qualifica (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: ente (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: ufficio (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: div (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: indirizzo (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: cap (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: citta (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: pv (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: nazione (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: telefono (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: codice (TEXT ; Size: 255 ; Req.: Falso)
'------FLD: annotazioni (MEMO/HYPER ; Size: 0 ; Req.: Falso)
------IDX: citta_cognome_nome_ente_ufficio
---------citta
---------cognome
---------nome
---------ente
---------ufficio
------IDX: citta_ente_ufficio_cognome
---------citta
---------ente
---------ufficio
---------cognome
---------nome
------IDX: cognome_nome_ente_ufficio
---------cognome
---------nome
---------ente
---------ufficio
------IDX: ente_ufficio_cognome_nome
---------ente
---------ufficio
---------cognome
---------nome
------IDX: pcnum
---------pcnum
===========================