Newsgroup: it.comp.lang.visual-basic
Titolo: Non e' uno spreco?

Come dice l'Help di VB...
È consigliabile utilizzare l'istruzione Option Explicit per evitare di
digitare in maniera errata il nome di una variabile esistente oppure di
creare confusione nel codice nel quale l'area di validità della variabile
non è chiara.
Cioe' si consiglia l'obbligo della dichiarazione di una variabile. Questo
non compromette le prestazioni?
esempio pratico:
private sub Command1_click
    Dim a
    Dim b
    Dim c
    Dim d
    Dim e
    Dim f
    Dim T
    T=a+b+c+d+e+f
End Sub
impegna le stesse risorse di:
private sub Command1_click
    T=a+b+c+d+e+f
End Sub
???

non compromette le prestazioni?
No, al contrario. Se non dichiari una variabile questa viene definita
automaticamente Variant, e l'accesso in lettura e scrittura ad un Variant è
molto più lento dell'accesso ad una variabile di altro tipo. Nel tuo esempio
nopn cambierebbe nulla, perchè non dichiari il tipo della variabile e viene
assunto per defaule il variant, ma se avessi scritto Dim a As Integer ecc...
il codice sarebbe stato più veloce.

Sicuro?
Io credevo che con variabili variant, non dovendo fare il controllo di
dimensione, il codice fosse piu' veloce.
Il difetto delle variant e' quello di occupare piu' memoria del necessario.
Il fatto di dimensionare (dim) le variabili all'inizio fa si che venga
allocato lo spazio in memoria in un' unica operazione.
il segreto sta nel fare una sola riga con un unico dim es:
Dim sPippo as String, nPluto as long ecc...
e' possibile comunque dimensionare le variabili senza le dim utilizzando gli
appositi simboli, es:
sPippo$ = "Testo" dimensiona sPippo come String e non come variant.
ciao,
Alessandro Scardova
scar...@tin.it
http://space.tin.it/computer/ascardov/


Da qualche parte devi comunque dichiararle. Option Explicit ti permette di
impedire la compilazione. Altrimenti riscontreresti l'errore di variabile
non dichiarat solo in esecuzione.
Ciao
Luca

non dichiarat solo in esecuzione.
Beh, no: VB permette (purtroppo) la dichiarazione implicita. Cioè se non
metto Option Explicit io in qualsiasi momento nel codice posso fare:
t="tyui" o t$="tyui" e automaticamente VB dichiara sul posto una variabile t
rispettivamente variant o string. Questo è il motivo per cui puoi sbagliare
a scrivere il nome della variabile che siccome non sarà inizializzata (0 o
stringa vuota) produce bug sottili a volte non chiarissimi. O non ho capito
bene quello che intendevi? (nel caso, scusami).
Domenico


Veramente, in entrambi i casi, hai utilizzato ben 16 * 7 bytes ( = 112).
Gia', perche' hai dichiarato TUTTE le variabili con il tipo di default ossia
VARIANT (1 variant = 16 bytes).
Abituati a dichiarare TUTTE le variabili che usi e con il TIPO adatto!
private sub Command1_click
    Dim a As Integer
    Dim b As Integer
    Dim c As Integer
    Dim d As Integer
    Dim e As Integer
    Dim f As Integer
    Dim T As Long
    T = a+b+c+d+e+f
End Sub
cosi', ad esempio, usi solo 2*6+4 bytes (= 16)
Bel risparmio, rispetto ai 112 di prima, no?
--
Roal Zanazzi
z...@iol.it

automaticamente Variant,
  E' vero che la gestione delle variabili Variant sono pesanti per il
VB ma e' sufficiente utilizzare i cari vecchi identificatori per le
variabili (%, &, $...) e sei a posto. :-)
  Ciao :-)
  Massimo
  Nell'indirizzo, inserire una "h" tra la "t" e la "u"
  In the address, insert an "h" between the "t" and the "u"

sPippo$ = "Testo" dimensiona sPippo come String e non come variant.
Questo e' vero e, in teoria, non e' diverso da sPippo As String.
Comunque qui entra in gioco il gusto e l'esperienza personale.
Ad esempio, avendo esperienza di C/C++ e Pascal, preferisco di gran lunga la
scrittura Dim sPippo As String, piuttosto che quello schifo di $.
--
Roal Zanazzi
z...@iol.it

dimensione, il codice fosse piu' veloce.
No! E' nel caso dei Variant che il sistema di run-time deve ogni volta
verificare il tipo. Secondo alcuni test l'accesso ad un variant č circa del
50% piů lento rispetto ad Integer e Long e del 30% rispetto a Single e
Double.

Bah!
Io consiglio a tutti di leggere il Capitolo 5 del libro
"Un diverso approccio alla creazione del codice con Visual Basic"
Del libro "Advanced Visual Basic 5" (by TMS - Mondadori Informatica) che da
un bel po' di regole sull'utilizzo delle variabili. Non ultima una piccola
regola dove spiega tutti i pro ed i contro sull'utilizzo di variabili di
tipo variant, giungendo ad'una interessante conclusione......
E' inutile preoccuparsi di velocita' di int o di variant.... A che serve ?
Solo se si stanno scrivendo applicazioni critiche che fanno migliaia e
milioni di calcoli.... Ma a questo punto il problema e' : E' giusto
utilizzare VisualBasic per queste applicazioni ?
Le stesse considerazioni vanno fatte anche per cio' che riguarda lo spazio
occupato dalle variabili.
Nella programmazione moderna "standard" conta molto il tempo necessario per
lo sviluppo e l'apertura del codice verso implementazioni future... e non se
l'applicazione e' di qualche millesimo di secondo piu' veloce...o se
ottimizza al meglio (di qualche byte) la memoria.
Vincio

Double.
Scusate l'intrusione ragazzi, ma credete possibile che oltrepassato il 2000,
dove un PC entry level sarà un PII 500MHz con vagonate di memorie Dimm,
dischi ULTRASCSI da 10000 giri di qualche Terabyte, sarete ancora tutti li a
discutere se è più veloce una variant o un integer?
:-x
Non mi fraintendete: vorrei solo farvi notare che è ormai una storia vecchia
che una 500 ottimizzata al massimo non va come una Ferrari.
Se volete proprio che VB vada più veloce, togliete la B e metteteci la C ed
un paio di +.
:-)
Ciao
--
-
MIX (VB5SP3)
post...@yahoo.com
80 links ai siti VB
http://space.tin.it/computer/gaais
http://www.tempolibero.com/user/mix/
 (alternativo)
-

... giungendo ad'una interessante conclusione......


Mi sembra una filosofia abbastanza sbagliata. Se così fosse ci aspetta un
futuro con dei pc che avranno più RAM che HD, schermati da una parete di 2
cm di piombo ed il tutto immerso in una colata di cemento armato. Se una
cosa può essere fatta in minor tempo e senza sprechi di risorse non vedo
altro modo per farla. Leggendo queste righe mi vien da piangere pensando ai
tempi in cui confrontavo la velocità di esecuzione di una funzione
programmata con un metodo iterativo e la stessa con la ricorsione (n!)
..per la cronaca vinceva naturalmente il metodo iterativo.
Ciao Marco
 
-- 
Remove xxx from E-mail.


Io toglierei anche la V... tanto, associata alla C e' finta... (naturalmente
sto parlando di VisualC++, che di Visual nel senso di RAD non ha molto...)
--
Roal Zanazzi
z...@iol.it


Si, bei discorsi, peccato che nella maggior parte dei casi si parla di
secondi e non millisecondi e di qualche centinaia di KB, non di byte...
Naturalmente, se riporti le tue riflessioni su applicazioni di livello medio
(ossia quelle che un programmatore professionista fa normalmente per
venderle), se invece stai parlando di piccoli programmini che fanno 2+2=4,
allora non sono comunque d'accordo :-)
Gia', perche' e' stupido fare 2+2=4 utilizzando 3 variant, non so se mi
spiego :-)
--
Roal Zanazzi
z...@iol.it

poi passo io con la mia 500 super-ottimizzata e ti frego :-)
Condanni quindi i programmatori a lottare con i limiti estremi di un
linguaggio invece che a sviluppare con dei mezzi più idonei?
E' vero che si può fare di tutto, che spesso i mezzi messi a disposizione
dalle aziende sono di 2 generazioni indietro, che non tutti hano a
disposizione i $$, ma qui si va a spaccare i bit!
Ciao
P.S. per la prova di velocità ci vediamo a Monza, Roal ci mette la 500 ed io
400Kg di zavorra.
Qualcuno cortesemente ci presta una Ferrari?


...


Vincio

un paio di +.
dove notoriamente la gente usa un long double al posto di un char :-)
Ciao Bruno

 
Sulla velocità di esecuzione, sono daccordo. Ma sulla velocità di creazione
e debug delle applicazioni avrei dei dubbi (Ma una esperienza molto
superficiale del c).
By. GPS

linguaggio invece che a sviluppare con dei mezzi più idonei?
  Immagino che tu sia il tipo che per eliminare una mosca usa un
bazooka. :->>>
  P.S. Io ho utilizzato i Variant giusto un paio di volte in oltre 5
anni di utilizzo del VB proprio perche' non avevo scelta e turandomi
il naso. :-D



Aspetta, dovrei avere un modellino in scala ridotta (cosi' sono sicuro di
vincere) :-)
--
Roal Zanazzi
z...@iol.it

bazooka. :->>>
Il problema è che sono astigmatico e non riesco a beccarla...
CIAO


...

Hai mai visto Borland C++Builder?
VisualC++ in confronto e' un dinosauro (nel senso di arcaico).
--
Roal Zanazzi
z...@iol.it

 rispettivamente variant o string. Questo è il motivo per cui puoi sbagliare...
Scusate se mi intrometto in questi discorsi filosofici.   Anche se sono
nuovo (o quasi) su questo NG, vorrei dire anche la mia.
Tempo fa mi era capitato di scrivere qualcosa come:
...
  arr(i) = O           ' ho usato per errore la lettera O anzichè zero
...
non avevo usato la lettera O per alcuna variabile, e il programma
funzionava bene perchè nella variabile O trovava zero.
In una modifica successiva, nella stessa routine ho aggiunto un pezzo di
codice che utilizzava la O come variabile intera come indice di un ciclo
FOR..NEXT  : Potete immaginare che, nonostante il nuovo pezzo fosse
perfettamente OK non funzionava più niente, e sono diventato pazzo per
capire cosa stava succedendo, perchè la mia attenzione si concentrava
sul pezzo aggiunto, dando per scontato che quello preesistente era a
posto.
Quindi, per quanto mi riguarda:
Option Explicit   SEMPRE
Niente %,&,$ ma nomi puliti, costruiti secondo una mia convenzione
Dichiarazione delle variabili precisa a seconda della funzione
Variant solo se non si può fare altrimenti
VBasic per il corpo principale del programma applicativo
C++ o Assembly per OCX, DLL per calcoli che richiedono velocità
GOTO e GOSUB:  orrore
Accetto critiche.            Bepi
-- 
/-------------------------------------------------\
| Bepi Rospi                                      |
|                                                 |
| mailto:
be...@multiwire.net
                       |
\-------------------------------------------------/


No, secondo me non è affatto da buttar via. Tra l'altro VB6 permette anche
la compilazione di controlli "windowless", e così anche il consumo di
risorse diminuisce molto. Inoltre, in genere negli ocx difficilmente servono
calcoli da fare in maniera velocissima, quindi secondo me VB va benissimo.
Rimane il problema del runtime. Per VB5 il problema è risolto perché in
Win98 ci sono le dll necessarie. Ma chi ha ancora il Win95 che fa? e se un
controllo è scritto in VB6 si dovrà pur sempre scaricare anche msvbvm60.dll.
Fra parentesi, che gli costava a mettere questo file in Win98, visto che VB6
e win98 sono usciti quasi insieme?
Domenico

Accetto critiche.            Bepi
Nessuna critica, hai elencato le regole principali per un buon
programmatore.
Appoggio in pieno!
--
Roal Zanazzi
z...@iol.it


E si' gia', si' gia'... :-)
E poi quando uscira' VB7... e poi quando uscira' Windows2000...
Dai scherziamo? l'idea di installare il runtime di VB insieme al SO e' stata
una vaccata... pardon, e' stato lo "zuccherino" per tutti i programmatori VB
che DA ANNI rompono le palle chiedendo di togliere 'ste dannate DLL di
runtime.
E poi il mese dopo tirano fuori VB6 e il giochino ricomincia da capo!
Ragazzi, vi rendete conto che gia' ora abbiamo un sacco di casini con le
diverse versioni di DLL (che se cambi versione rischi che non funziona piu'
niente)?
Su Windows2000 cosa ci installeranno? le runtime di VB 5,5/SP3,6,7,etc.
etc...?
Ma perche' invece di fare queste "scappatelle", alla M$ non risolvono una
volta per tutte il problema? Forse perche' hanno le mani legate dalle scelte
(stupide) che hanno fatto fin dalle prime versioni di VB?
A mio parere (non sono, per mia fortuna, un dipendente M$, e cio' vuol dire
che uso il cervello, non il portafogli!) ci sono 2 soluzioni al problema
delle DLL di runtime di VB:
1) fare 1 (e una sola 1!) DLL (chiamiamola MSVBVM.DLL), che non sia
specifica per una versione di VB, ma venga aggiornata per le nuove versioni
e contemporaneamente rimanga utilizzabile dalle versioni precedenti.
Cosi' intanto si risolve un problema: serve solo 1 DLL per tutte le versioni
di VB.
Questo pero' e' un palliativo, non si risolve il problema alla radice.
2) Quello che da anni si chiede alla M$: la possibilita' di compilare EXE in
VB che non abbiano la necessita' del runtime.
Questo E' fattibile, almeno da VB5 in poi, si tratta di far diventare VB un
po' piu' simile agli altri linguaggi/compilatori, con la possibilita' di
utilizzo di file OBJ compilati e quindi di file LIB (librerie statiche), in
alternativa alla DLL.
[NOTA: questo alla Borland lo fanno da anni]
Scusate lo sfogo, sto scaricando un file zip da qualche mega con un
programma VB dentro... :-(
--
Roal Zanazzi
z...@iol.it

Questo pero' e' un palliativo, non si risolve il problema alla radice.
Perché solo un palliativo? Chi scrive con MFC non ha anche lui i runtime?
solo che appunto hanno compatibilità all'indietro per cui ce n'è una sola
per tutti (io invece sul mio hd ho già almeno 6 runtime di vb). Poi,
naturalmente, come si fa a non essere d'accordo quando dici che affiancata a
questa opzione dovrebbe esserci l'altra della compilazione senza dipendenze?
Però ho dei confidenti alla Microsoft e so per certo che VB28 risolverà il
problema (ma ci vorrà SP7 perché il compilato giri davvero).
Scusate l'ironia amara: è che avevo sperato molto in questa ciofeca di VB6.
Domenico

 VisualC++ in confronto e' un dinosauro (nel senso di arcaico).
No non lo ho mai visto, me lo descrivi?

Roal,
Ho fatto le prove ed hai ragione!
Il variant e' in debug 2 volte piu' lento del long e 8 volte in compilato.
(su vb6)
concordo con quello che dici sui dimensionamenti con i codici dopo la
vraiabile,
ciao,
Alessandro Scardova
scar...@tin.it
http://space.tin.it/computer/ascardov/

GOTO e GOSUB:  orrore
Cosa sono GOTO e GOSUB ?
Ciao, Pipol!
Piero


VB28, nel senso di VB2028? (denominazione indicativa di problemi dei
prodotti M$ con l'anno 2000 :-)
--
Roal Zanazzi
z...@iol.it

...

Sono OT, ma chi se ne frega (una volta ogni tanto lo faccio anch'io :-)
Borland (oops, Inprise) C++Builder 3:
- ambiente RAD (Rapid Application Development), ossia come VB (costruzione
intefaccia grafica con drag & drop e proprieta' degli oggetti)
- pieno supporto allo standard C++
- completa interoperabilita' con Borland Delphi (la libreria VCL e' la
stessa, in Pascal!); compila anche sorgenti Delphi.
- la libreria di oggetti puo' essere dinamica (tipo DLL) o statica (tutto
nell'EXE).
- insomma, tutto (o quasi) quello che uno sviluppatore sogna: semplicita'
nella creazione dell'interfaccia utente e piena potenza del codice C++.
Riassunto: un sogno!
alla faccia di quel dinosauro di VisualC++ !
(anche per oggi ho fatto la mia buona azione quotidiana :-)
--
Roal Zanazzi
z...@iol.it