Newsgroup: it.comp.lang.visual-basic
Titolo: [VB6] Me la spiegate questa ?

VB6+SP5
Dim l As Long
l = 3600 * 10  ==> Questa riga genera errore di overflow
l = 36000      ==> Questa fila via liscia...
Paolo

ToSka ha scritto:

Non ci credo nemmeno se lo vedo! :-o
-- 
Emanuele Torrenti
Registered Linux User #409659
http://torrenti.altervista.org


l = 3600& * 10
Marco.

 Marco.
Cosa intendi? Toska non ha scritto cosi
-- 
Greg

 Dim l As Long
Ma la var si chiama uno o elle?
-- 
Greg

 l = 36000      ==> Questa fila via liscia...
Il 3600 (se non specificato altrimenti) VB lo imposta come un integer, per
cui non riesce a contenere il risultato dell'operazione.
il 36000 invece, visto che in un integer non ci sta, VB lo imposta
direttamente come un long e quindi il problema scompare.
La soluzione, come già detto, è quella di dire a VB che il 3600 è un long,
in modo che possa contenere il risultato dell'operazione.

 long, in modo che possa contenere il risultato dell'operazione.
Grazie della spiegazione, pensavo di saper tutto, invece non si finisce mai
di imparare.
Ho provato la riga di Coronam, che non capivo, e invece funziona e conferma
quello che dici tu.
La cosa che mi lascia sbalordito, e che non ho mai visto scritto da nessuna
parte, è che si può scrivere un valore di un certo tipo.
Fino ad oggi sapevo che era la variabile  a dover essere di un certo tipo,
ma non un valore!
Grazie a Toska, grazie al ng.
-- 
Greg

 ma non un valore!
Infatti č piuttosto stupido come bug. Se sto assegnando una variabile
long mi spiega MS perchč mai pensa di utilizzare un integer? ;-)
-- 
<-------- The information went data way -------->
News 2002 [v 2.07] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 long mi spiega MS perchè mai pensa di utilizzare un integer? ;-)
Bug?
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.

 Bug?
Ah gią... Una features, dimenticavo.
-- 
BASIC is to computer programming as QWERTY is to typing.  - Seymour Papert



Vedo che non ero il solo a non sapere di questa cosa... io non riuscivo a
crederci.
Non sapevo neppure quello che ha suggerito coronam.
Grazie e tutti per le spiegazioni.
Paolo

 Ah già... Una features, dimenticavo.
Diciamo che è una normale caratteristica di qualunque ambiente di 
sviluppo.
VB, in questo, è molto ingannevole, perchè consentendo una tipizzazione 
molto blanda, disabitua lo sviluppatore al rigore della gestione dei 
tipi, e poi diventa subdolo perchè ha dei tipi 'piccoli'.
Ma il concetto che si debba sempre valutare i tipi intermedi di una 
qualunque operazione, è comunque una cosa comune a tutti, e direi che 
sia una delle basi dell'informatica.
Ciao


 sia una delle basi dell'informatica.
Esatto, ma qui si parla di una costante numerica. Trovo assurdo che 
all'assegnazione di un tipo VB crei una variabile di un altro tipo 
all'interno dell'assegnazione.
-- 
Avoid GOTOs completely if you can keep the program readable.


 all'interno dell'assegnazione.
Quindi, tu vorresti che VB utilizzi, per una *costante*, un tipo 
piuttosto che un altro, a seconda del tipo della variabile a cui poi 
sarà assegnato il risultato.
Adesso, capisco che VB ci abbia abituato agli automatismi, ma 
addirittura pensare che una formula matematica debba venire risolta in 
modo diverso per adeguarsi alle nostre lacune di formulazione (perchè 
VB consente di tipizzare anche le costanti numeriche, solo che molti si 
dimenticano di mettere &, # o @ assieme alle cifre), rappresenta il top 
dell'indeterminismo.
Perdonami, ma sono contrario a ciò che sostieni.
VB ragiona benissimo, e se valuti molti miei post precedenti, vedrai 
che tendo a tipizzare le costanti per cui non voglio che venga usato il 
Integer o il Double. Il fatto che molti non lo facciano, non significa 
che l'ambiente abbia un bug.
Del resto, non capisco perchè VB dovrebbe operare in modo diverso da 
come operano TUTTI gli altri ambienti seri, che anzi sono ancora più 
rigorosi.


 
perche' l'espressione e' valorizzata 'sempre' al tipo piu' 'piccolo' 
tenendo conto solo della parte destra dell'assegnazione
pensa al caso in cui al posto di costanti ci sono variabili, in questo 
caso solo a runtime si potrebbe sapere se c'e' la necessita' di 
promuovere il tipo della espressione
e' una feature piuttosto comune anche di altri linguaggi e compilatori
P.S. si potrebbe discutere per secoli quale sia l'implementazione piu' 
corretta se l'attuale o quella in cui si tiene conto anche del tipo 
della variabile destinazione

 della variabile destinazione
Infatti, tra l'altro, ipotizziamo che la variabile di destinazione si un
double, in questo caso, rendere double i due valori, rallenterebbe
inutilmente il calcolo visto che andrebbe fatto comunque in due passaggi.
Forse, semplicemente, avrebbero dovuto spiegare meglio la cosa nella guida.

 promuovere il tipo della espressione
Stiamo parlando di costanti numeriche però. Una costante numerica che
non è stata tipizzata in una assegnazione a parer mio non dovrebbe 
diventare una trappola. Allora sarebbe meglio rendere esplicita anche
l'assegnazione dei tipi alle costanti.
-- 
Another megabytes the dust.


 l'assegnazione dei tipi alle costanti.
Infatti, anche le costanti andrebbero tipizzate.
Ma la gente si dimentica di farlo.
Però, il fatto che uno lavori in modo approssimativo, non autorizza ad 
incolpare l'ambiente.
Tutto qui.


 l'assegnazione dei tipi alle costanti.
Le costanti numeriche di default sono tipizzate a Integer.
Comunque, io non so niente di ingegneria informatica, però credo che 
promuovere la variabile interna usata per il calcolo non sarebbe una cattiva 
idea (ma come, i compilatori "seri" mi spaccano il c@//o quando moltiplico 
due byte perchè dicono "stai attento che potresti non starci dentro" e poi 
loro con gli interi fanno quello che vogliono? Mi pare ovvio che per 
moltiplicare due int a 16bit serva una var di destinazione a 32bit! Mica uso 
un intero per sfruttare solo i primi 8 bit!).
Ciao
-- 
Free .Net Reporting Tool - 
http://www.neodatatype.net
 

 incolpare l'ambiente.
Stai confondendo l'approssimazione dell'utente con le dimenticanze di
chi ha realizzato l'ambiente. La variabile di destinazione è un LONG,
non si capisce perchè l'operazione dovrebbe fallire. 
Sarebbe corretto che dietro una option explicit il compilatore 
generasse errori sulle costanti non tipizzate.
-- 
If a train station is where the train stops, what is a work station?


 
su questo punto hai perfettamente ragione visto che tutta l'espressione 
e' una costante , si potrebbe 'ottimizzare'
qualcuno ( linguaggio ) lo fa , qualcun'altro no :-(
resta comunque il fatto fondamentale che il VB nno guarda la 
destinazione, cosa che francamente non mi sembra facciano neanche gli 
altri linguaggi.
P.S. a volte, con il C, mi fa comodo avere l'aritmetica 'in modulo' 
senza segnalazioni di errori e piantamenti vari ( ma ho a che fare con 
applicazioni 'limite' )

 generasse errori sulle costanti non tipizzate.
Potrei anche essere d'accordo.
Ma in realtà le costanti sono tutte tipizzate.
Se non indichi niente, sono integer, altrimenti puoi definirle.
Ciao


 Se non indichi niente, sono integer, altrimenti puoi definirle.
Non funziona così una implementazone seria. Se usi option explicit 
quando usi una variabile non definita si impianta il compilatore e 
giustamente si inca%%a, non si permette di assegnare un tipo di 
default. Idem dovrebbe essere allora per le costanti. Non ne dichiari
il tipo? Si blocca e segnala l'errore. Ma in compilazione non a 
runtime.
-- 
IBM: Ici Beaucoup Merde


 runtime.
Si blocca a runtime perchè è un overflow. Non può sapere il valore che 
otterrà, se nella formula c'è una variabile, finchè non ci gira dentro.
Comunque, VB consente di tipizzare. Poi, se uno non lo fa, sono fatti 
suoi. Ma non venga a dirmi che è un bug.


 otterrà, se nella formula c'è una variabile, finchè non ci gira dentro.
Vedo che non mi hai capito. dico che *SE* l'avessero implementata un 
po' meglio si *DOVREBBE* bloccare in compilazione quando *NON 
ASSEGNI* il tipo alle costanti.
 
-- 
Everyone is entitled to my opinion! 


 Allora non hai letto il mio messaggio.
Si, hai ragione tu.


 Si, hai ragione tu.
Scusa, ma pensi di fare il *grande* lasciandomi la ragione, giusto 
perchè del discorso non ci hai capito una ma%%a? La linea Var_Long = 
5.1 * 3.2 verrebbe valutata NELL'IDENTICO MODO di Debug.Print CStr 
(5.1 * 3.2) perchè SOLO se si trattasse di INTERI dovrebbero essere 
convertiti in LONG nel nostro caso. E l'ho anche specificato:
"E' un long? Allora TUTTE le costanti numeriche INTERE che siano 
long. E' un double? Allora tutte le 
costanti numeriche REALI siano double."
Se ti poni sul piedistallo non cominciare neppure a disquisire la 
prossima volta.
-- 
"Close the fridge door, I'm dressing!" cried the mayonnaise 
