Ricorsione !!!!
DANIELE BALZI
premetto che sono un programmatore C e che solo nell'ultimo periodo mi sto
avvicinando a VB.
Ho un problema con la ricorsione:
cioè una variabile locale definita all'interno di una procedura ricorsiva,
non mantiene il valore giusto.
C'è qualche settaggio particolare da eseguire?
Che cosa è lo stack overflow?
Grazie D.K.
Jimi
> cioč una variabile locale definita all'interno di una procedura ricorsiva,
> non mantiene il valore giusto.
> Che cosa č lo stack overflow?
Ma non sei un programmatore C ?
Hai esaurito lo spazio di memoria indirizzabile per il
processo corrente.
Forse la tua procedura ricorsiva "ricorre" troppo.
Stefano Minardi
cosě anche in C?).
Lo "stack overflow" č il rimpimento dello stack di chiamata, cioč un buffer
nel quale vengono memorizzate le informazioni quando esegui una call ad una
routine e che permette al programma di ripristinare la situazione quando
ritorna alla chiamante. Nello stack finiscono varie cose fisse (indirizzo
del chiamante etc.) e le variabili passate alla funzione. Se ne evince che
si dovrebbero passare pochi argomenti in chiamate ricorsive. Chiaramente
dipende dal numero di ricorsioni - p.es. se implementi un QuickSort
ricorsivo e tenti di ordinare 100.000 elementi vai di sicuro in overflow,
anche se passi pochi parametri. In questi casi si usa una versione non
ricorsiva dell'algoritmo, piů brutta ma piů efficiente (fra l'altro la
ricorsione č spesso un fattore di rallentamento, perché una call costa molto
piů di un Goto).
----------------------------------------------------------------------
Stefano Minardi
zet...@mclink.it
----------------------------------------------------------------------
the NET Fury
"Stefano Minardi" <zet...@mclink.it> ha scritto nel messaggio
news:896vdf$4hl$1...@news.mclink.it...
> Devi dichiarare la variabile Static se vuoi che mantenga il valore (non è
> così anche in C?).
>
> Lo "stack overflow" è il rimpimento dello stack di chiamata, cioè un
buffer
> nel quale vengono memorizzate le informazioni quando esegui una call ad
una
> routine e che permette al programma di ripristinare la situazione quando
> ritorna alla chiamante. Nello stack finiscono varie cose fisse (indirizzo
> del chiamante etc.) e le variabili passate alla funzione.
se usi il BYVAL, in quanto VB per default passa le variabile per
riferimento!
quindi probabilmente il programma gli va in stack overflow per la mole di
dati che viene dichiarata all'interno della procedura ogni volta che viene
chiamata! Forse sarebbe il caso di dichiarare "se possibile ai fini della
ricorsione" le varibili (matrici, oggeti o altro) a livello di modulo
lasciarle shared.
> Se ne evince che
> si dovrebbero passare pochi argomenti in chiamate ricorsive. Chiaramente
> dipende dal numero di ricorsioni - p.es. se implementi un QuickSort
> ricorsivo e tenti di ordinare 100.000 elementi vai di sicuro in overflow,
beh, anche questo è ovviamente importante!
> anche se passi pochi parametri. In questi casi si usa una versione non
> ricorsiva dell'algoritmo, più brutta ma più efficiente (fra l'altro la
> ricorsione è spesso un fattore di rallentamento, perché una call costa
molto
> più di un Goto).
molto più brutta, molto più efficiente...
il GOTO andrebbe abolito :) , certo ti permette di ottimizzare il codice, ma
per i puristi è un'eresia!
del resto è ovvio che laddove sia possibile implementare una funzione
iterativa al posto di una ricorsiva nel 99% dei casi essa è più efficiente!
---
byeZ
Alessandro Cerioni
- Sunspot "TSK Squad" www.tsksquad.net
aiutamici co-webmaster http://www.aiutamici.com
Joshua
Lo stack overflow si verifica quando in una routine ricorsiva non esiste, o
non funziona, il codice di arresto, quello che deve porre termine alla
ricorsione. Ogni chiamata a funzione viene registrata nello stack, fino a
completa occupazione di quello spazio di memoria.
Quanto alla variabile che non mantiene il valore giusto, ciň accade perchč
le variabili locali, in VB come nel C, vengono allocate ad ogni chiamata
della funzione in cui vengono dichiarate, e distrutte all'uscita dalla
funzione stessa. Per evitare ciň, e far conservare alla variabile il valore
giusto, devi dichiararla STATIC (vedi Help al riguardo)
--
Lunga vita e prosperitŕ
Joshua
mailto://jos...@mclink.it
DANIELE BALZI <flb...@tin.it> wrote in message
896tep$g2d$1...@nslave2.tin.it...
> Ciao a tutti,
> premetto che sono un programmatore C e che solo nell'ultimo periodo mi sto
> avvicinando a VB.
> Ho un problema con la ricorsione:
> cioč una variabile locale definita all'interno di una procedura ricorsiva,
> non mantiene il valore giusto.
> C'č qualche settaggio particolare da eseguire?
> Che cosa č lo stack overflow?
>
> Grazie D.K.
>
>
Zanna
the NET Fury ha scritto nel messaggio <8977ll$nq1$1...@nslave2.tin.it>...
Completamente d'accordo con il tuo post ma questo lapsus?
>se usi il BYVAL, in quanto VB per default passa le variabile per
>riferimento!
ByVal = Per Valore
ByRef = Per Riferimento
Ciao
DANIELE BALZI
Essendo io un programmatore C, conosco perfettamente che cosa si intende per
stack overflow in ambiente C; ho ipotizzato una gestione particolare in VB.
Comunque il problema è il seguente:
Ho una variabile locale dichiarata all'interno della funzione ricorsiva.
Tale variabile locale al ritorno da una chiamata ricorsiva, invece di
mantenere il "vecchio" valore cioè quello relativo al proprio "record di
attivazione" si comporta in modo strano e cioè come se fosse una variabile
definita static. Eseguendo il debug della variabile mi accorgo che,
all'uscita di una chiamata ricorsiva, alla variabile locale viene attribuito
un valore Nothing invece di quello che prima vi era prima della chiamata
ricorsiva.
Grazie per la vostra attenzione D.K.
Zanna
DANIELE BALZI ha scritto nel messaggio <898gua$ptn$1...@nslave2.tin.it>...
Nothing?
E' una var. che referenzia un oggetto?
La usi la Option Explicit?
Se tu fai una funzione così:
Function Ricorsiva(ByVal n As Integer)
Dim i As Integer
i = 10
n = n \ 2
If (n > 1) Then
Call Ricorsiva(n)
End If
Call MsgBox(i) <=== Scrive 10
End Function
quindi ti mantiene il valore corretto.
Ciao
the NET Fury
"Zanna" <zntf...@tin.it> ha scritto nel messaggio
news:898foi$fu0$1...@nslave1.tin.it...
appunto come dicevo io :) forse l'ho detto male io o tu hai capito male ;)
intendevo proprio dire che lo stack overflow è molto più probabile quando si
passano variabili tramite BYVAL alla procedura ricorsiva
e che CMQ se non è importante che per ogni sessione la variabile abbia uno
specifico valore, allora è anche meglio dichiarala a livello di modulo con
condivisone di tipo shared :) concordi?
è CMQ strano che condoscendo il C non si sappiano i livelli di esistenza e
di condivisione o visibilità degli oggettii (siano esse funzioni o dati) il
C è mitico per le cose che ci può fare proprio sotto questo punto di vista!
:)
---
byeZ,
the NET Fury
"Zanna" <zntf...@tin.it> ha scritto nel messaggio
news:898o2n$b5l$1...@nslave1.tin.it...
>
CUT
> Se tu fai una funzione cosě:
>
> Function Ricorsiva(ByVal n As Integer)
> Dim i As Integer
> i = 10
> n = n \ 2
> If (n > 1) Then
> Call Ricorsiva(n)
> End If
> Call MsgBox(i) <=== Scrive 10
> End Function
si okkey, ma ogni volta che richiami la funzione viene allocato nuovo spazio
per gestire la variabile "i", in questo caso sarebbe piů corretto
dichiararee "i" a livello di modulo e non interna alla funzione, se poi si
presuppone che le chiamate possono essere tante, va aggiunto che
un'ulteriore ottimizzazione sia di stack che di prestazioni la si ottiene
passando "n" per riferimento e quindi se il valore della variabile da
comunicare deve essere mantenuto la chiamata alla funzione sarebbe:
let appoggio=pippo
call Ricorsiva (appoggio)
cosě che su pippo il valore non ti cambia!
ma poi che funzione č se non ritorna alcun valore ???
;)
Stefano Minardi
>riferimento!
>dati che viene dichiarata all'interno della procedura ogni volta che viene
>chiamata! Forse sarebbe il caso di dichiarare "se possibile ai fini della
>ricorsione" le varibili (matrici, oggeti o altro) a livello di modulo
>lasciarle shared.
In ogni caso una chiamata passa il puntatore agli argomenti della funzione
nello stack (ovviamente i registri non bastano se si usa piu' di qualche
robuccia e il compilatore non sara' certo cosi' ottimizzato da usarli).
Le variabili locali non vanno nello stack ma nella memoria allocata dal
programma, quindi non si ha stack overflow per questo.
Sicuramente puo' pero' essere un problema: se faccio mille ricorsioni di una
funzione che alloca un MB e' chiaro che alloco quasi un GB. Le variabili
shared a livello di modulo in questo caso particolare non servono, ma
potrebbero essere utili in molti casi di ricorsione.
>il GOTO andrebbe abolito :) , certo ti permette di ottimizzare il codice,
ma
>per i puristi è un'eresia!
Beh, giusto una questione di stile, perche' se devo ottimizzare fortemente
una routine, il goto lo uso eccome (in assembler non ci sono costrutti come
while :-) Molti anni fa ricordo di aver visto del codice illeggibile perche'
ai programmatori (che provenivano dal Fortran) non era stato insegnato l'uso
di goto in C: erano convinti che non esistesse. I loro istruttori non lo
avevano menzionato perche' screditato. Il risultato era che in alcune
routine venivano fatti salti mortali per uscire 'castamente' da cicli di
while (variabili settate 'artificialmente' etc.).
Quando ci vuole, ci vuole.
Zanna
Stefano Minardi ha scritto nel messaggio <899pk5$59g$1...@news.mclink.it>...
>>il GOTO andrebbe abolito :) , certo ti permette di ottimizzare il codice,
>ma
>>per i puristi è un'eresia!
>
>Beh, giusto una questione di stile, perche' se devo ottimizzare fortemente
>una routine, il goto lo uso eccome (in assembler non ci sono costrutti come
>while :-)
Già, però VB li ha... ed ha anche il modo di saltarne fuori...
Molti anni fa ricordo di aver visto del codice illeggibile perche'
>ai programmatori (che provenivano dal Fortran) non era stato insegnato
l'uso
>di goto in C: erano convinti che non esistesse. I loro istruttori non lo
>avevano menzionato perche' screditato. Il risultato era che in alcune
>routine venivano fatti salti mortali per uscire 'castamente' da cicli di
>while (variabili settate 'artificialmente' etc.).
>Quando ci vuole, ci vuole.
Intanto non si può più pensare la programmazione in modo procedurale come ai
tempi del QBasic o del Pascal, se lo si fa ancora allora non serve il goto,
ma una nuova ottica di programmazione.
Se non è così significa che i suddetti algoritmi erano o scritti male in
partenza o i linguaggio non disponeva di sistemi "intelligenti" (non conosco
il fortran).
Comunque in VB, nonostante quello che dicono i "nostalgici" l'unico caso in
cui il Goto è necessario è la gestione degli errori, ed è rimasto solo per
compatibilità.
Lo stesso help riporta:
Nota La presenza di troppe istruzioni GoTo può rendere difficile la
lettura e il debug del codice. Quando possibile, è consigliabile
utilizzareistruzioni di controllo strutturate (Do...Loop, For...Next,
If...Then...Else, Select Case).
Ciao
the NET Fury
"Zanna" <zntf...@tin.it> ha scritto nel messaggio
news:89mluq$hsf$1...@nslave1.tin.it...
CUT
> Intanto non si può più pensare la programmazione in modo procedurale come
ai
> tempi del QBasic o del Pascal, se lo si fa ancora allora non serve il
goto,
> ma una nuova ottica di programmazione.
> Se non è così significa che i suddetti algoritmi erano o scritti male in
> partenza o i linguaggio non disponeva di sistemi "intelligenti" (non
conosco
> il fortran).
il Fortran è un casino (almeno il F/77)
> Comunque in VB, nonostante quello che dicono i "nostalgici" l'unico caso
in
> cui il Goto è necessario è la gestione degli errori, ed è rimasto solo per
> compatibilità.
io sono un purista del codice, il programma deve essere leggibile anche se
commentato malamente... deve essere come un linguaggio parlato! pensa se
mentre fai un discorso salti ad un altro, poi esci fuori con tutt'altra cosa
quindi un'altra ancora e alla fine non ti ricordi più da dove eri partito!
ecco questo è l'uso del GOTO... CMQ ritengo che come utilità allora sia
meglio il GOSUB...RETURN, anche se poi bisogna fare ancor più attenzione!
oddio sono d'accordo che con il GOTO si ottimizza di molto il codice in
taluni casi particolari, ma andrebbe CMQ evitato o quantomeno sfruttatto
solo in routine Time-Critical.
> Lo stesso help riporta:
CUT (vabbé questo lo sappiamo tutti!)
io ancore specifico l'assegnamento con l'inutile [LET] :) figurati come sono
ridotto ;) eheheh
però ti garantisco che il codice è molto più leggibile!
---
byeZ,
Alessandro Cerioni
- Sunspot "TSK Squad" www.tsksquad.net
aiutamici co-webmaster www.aiutamici.com
Zanna
the NET Fury ha scritto nel messaggio <89obch$nb4$1...@nslave2.tin.it>...
>ciao,
>io sono un purista del codice, il programma deve essere leggibile anche se
>commentato malamente... deve essere come un linguaggio parlato! pensa se
>mentre fai un discorso salti ad un altro, poi esci fuori con tutt'altra
cosa
>quindi un'altra ancora e alla fine non ti ricordi più da dove eri partito!
>ecco questo è l'uso del GOTO... CMQ ritengo che come utilità allora sia
>meglio il GOSUB...RETURN, anche se poi bisogna fare ancor più attenzione!
E perchè lo dici a me che sono completamente d'accordo con te? (a parte la
storia sul GOSUB, fratello del GOTO)
>io ancore specifico l'assegnamento con l'inutile [LET] :) figurati come
sono
>ridotto ;) eheheh
>però ti garantisco che il codice è molto più leggibile!
Secondo me è più leggibile senza, comunque sembra che il LET consenta al
compilatore di ottimizzare un pochino l'assegnazione poichè capisce al volo
che l'uguale è un'assegnazione e non un confronto: come saprai il basic è
l'unico linguaggio che usa lo stesso simbolo per assegnazione e confronto,
il cui significato cambia solo dal contesto.
Ciao
Stefano Minardi
Si', fai vedere un Exit Do o un Exit For ad un purista C e vedrai!-) (E'
vero che in C esiste "break", ma non lo puoi usare in una situazione
nidificata di do/for come consente il Basic. Per il C perfino la Select deve
avere un break - il che poi torna molto utile.)
Onestamente, il Basic e' il linguaggio meno 'puro' che ci sia! Qui si parla
di puritanesimo, piuttosto. Exit Do e' un modo piu' carino di fare GoTo.
Spiegatemi poi come faccio in un caso come questo:
If MyFunc(x,y,z) Then Goto ErrQuit
dove ErrQuit fa un macello di cose prima di uscire dalla funzione? Replico
tutto il codice di ErrQuit dopo ogni chiamata ad una funzione?
>Nota La presenza di troppe istruzioni GoTo può rendere difficile la
>lettura e il debug del codice. Quando possibile, è consigliabile
>utilizzareistruzioni di controllo strutturate (Do...Loop, For...Next,
>If...Then...Else, Select Case).
Intanto dice "troppe", poi queste sono le chiose fatte per i principianti.
Nessuno scriverebbe mai "inzeppate il codice di GOTO e GOSUB", ovviamente.
Ma qualsiasi buon testo professionale di buona programmazione non tiene in
nessun conto queste storie.
>Intanto non si può più pensare la programmazione in modo procedurale come
ai
>tempi del QBasic o del Pascal, se lo si fa ancora allora non serve il goto,
>ma una nuova ottica di programmazione.
Non vedo cosa c'entri la programmazione procedurale con il GOTO. Io scrivo
codice non procedurale da un sacco di tempo (moooolto prima di VB e di
Windows) e ho sempre usato il GOTO *quando* serviva.
Stefano Minardi
>commentato malamente... deve essere come un linguaggio parlato! pensa se
>mentre fai un discorso salti ad un altro, poi esci fuori con tutt'altra
cosa
>quindi un'altra ancora e alla fine non ti ricordi più da dove eri partito!
>ecco questo è l'uso del GOTO... CMQ ritengo che come utilità allora sia
>meglio il GOSUB...RETURN, anche se poi bisogna fare ancor più attenzione!
Ecco, il GOSUB e' davvero una cosa che non vorrei piu' vedere. Pensare ad
una subroutine che utilizza le stesse variabili della chiamante mi fa
impazzire (gli errori si sprecano). E' rimasto da quando il Basic era
un'unica routine principale che non poteva avere funzioni richiamabili.
>oddio sono d'accordo che con il GOTO si ottimizza di molto il codice in
>taluni casi particolari, ma andrebbe CMQ evitato o quantomeno sfruttatto
>solo in routine Time-Critical.
Intendiamoci, non e' che io dica "usate il GOTO perche' e' un'istruzione
fondamentale". Quando io scrvo codice, il GOTO ci casca spesso, ma non uso
piu' di una-due label per funzione (effettivamente per lo piu' per uscire in
caso di errore di una funzione chiamata, quindi le label sono identiche in
tutte le funzioni, ho anzi un Addin che mi costruisce lo scheletro della mia
funzione-tipo). Neppure dico che serva a ottimizzare - non in VB, comunque,
dove l'ottimizzazione e' per lo piu' superflua (e' terribile in ogni caso).
In questo caso pensavo piuttosto a linguaggi un pochino di piu' basso
livello, dove il GOTO viene brutalmente tradotto in una jump dell'assembler.
Insomma, intendiamoci, io sono forse uno dei peggio rimpiballe sullo stile
del codice (se non e' formattato come dico io sono dolori) ma qualche GOTO
non e' la fine del mondo - basta che non si scrivano programmi tipo:
If (a > b) Then GOTO AmaggB
If (b>c) Then GOTO BmaggC
If (c>d) Then GOTO CmaggD
...etc.
A volte, pero', si sente la necessita' di una cosa del genere *proprio per
la leggibilita' del codice*, perche' se fra i vari IF intercorrono piu' di 5
righe a me da' fastidio, specialmente se si tratta di un IF/ELSE/ENDIF o di
un SELECT, perche' ogni spezzone di codice e' troopo grande, la visibilita'
d'insieme si annulla (proprio quello che accade con il GOTO) e perche'
voglio isolare ogni sezione. Ma in questi casi la soluzione non e':
If (a > b) Then
Una tonnellata di codice
Endif
If (b>c) Then
Un'altra tonnellata di codice
Endif
etc.
ma piuttsoto:
If (a > b) Then
AmaggB()
Endif
etc.
Indubbiamente piu' leggibile e ortodosso del GOTO, ma ditemi dove sta questa
grande perspicuita'? C'e' anche un vizio in questo, cioe' l'eccesso di call.
Ho visto programmi (alcuni ben fatti) nei quali era impossibile seguire la
catena delle chiamate ( a call b, b call c, c call d...). Codice cosi' mica
e' tanto dominabile, no? Tuttavia e' facile che capiti anche per caso - io
tendo a questo abuso, p.es., perche' fondamentalmente odio sezioni piu'
lunghe di una schermata, massimo due: il codice lo voglio vedere tutto
insieme.
Zanna
Stefano Minardi ha scritto nel messaggio <89pnf2$c46$4...@news.mclink.it>...
>>Già, però VB li ha... ed ha anche il modo di saltarne fuori...
>
>Si', fai vedere un Exit Do o un Exit For ad un purista C e vedrai!-)
Se le strutture C sono rimaste invariate da quando è nato e non includono
soluzioni più intelligenti è un problema del C e non del programmatore VB
>(E' vero che in C esiste "break", ma non lo puoi usare in una situazione
>nidificata di do/for come consente il Basic. Per il C perfino la Select
deve
>avere un break - il che poi torna molto utile.)
Proprio un'infinità di volte... ad esempio... dunque... vediamo... mmm....
boh.
Ma questo esce dal discorso sul Goto
>Onestamente, il Basic e' il linguaggio meno 'puro' che ci sia! Qui si parla
>di puritanesimo, piuttosto. Exit Do e' un modo piu' carino di fare GoTo.
>Spiegatemi poi come faccio in un caso come questo:
>
>If MyFunc(x,y,z) Then Goto ErrQuit
>dove ErrQuit fa un macello di cose prima di uscire dalla funzione? Replico
>tutto il codice di ErrQuit dopo ogni chiamata ad una funzione?
E a mettere il codice di ErrQuit in una sub non ci hai mai pensato?
Comunque se il tuo scopo è solo saltare parte del codice mi sembra MOLTO più
elegante e lineare scrivere
If Not MyFunc(x,y,z) Then
[Codice da saltare]
End if
[Codice ErrQuit]
>>Nota La presenza di troppe istruzioni GoTo può rendere difficile la
>>lettura e il debug del codice. Quando possibile, è consigliabile
>>utilizzareistruzioni di controllo strutturate (Do...Loop, For...Next,
>>If...Then...Else, Select Case).
>
>Intanto dice "troppe", poi queste sono le chiose fatte per i principianti.
Ok concesso il "troppe", il che comunque non afferma che "poche" siano
invecie consigliabili.
Comunque lo stesso VB è derivato da un "Beginners All-Purpose Symbolic
Instruction Code".
>Nessuno scriverebbe mai "inzeppate il codice di GOTO e GOSUB", ovviamente.
>Ma qualsiasi buon testo professionale di buona programmazione non tiene in
>nessun conto queste storie.
Già proprio come il "Hardcore Visual Basic" della Microsoft Press
(consultabile parzialmente sull'MSDN) dove al capitolo _1_ paragrafo _1_
"Language Purification" si cita tra le altre cose sul GOTO:
It has its uses, primarily with error traps. Because error handling is
inherently unstructured, an unstructured feature like Goto fits right in. If
you use Goto for any other purpose, however, chances are you’re writing bad
code. The C version of Goto actually makes some code easier to read as well
as more efficient, but that’s because C’s switch statement is less powerful
than Basic’s Select Case.
>>Intanto non si può più pensare la programmazione in modo procedurale come
>ai
>>tempi del QBasic o del Pascal, se lo si fa ancora allora non serve il
goto,
>>ma una nuova ottica di programmazione.
>
>Non vedo cosa c'entri la programmazione procedurale con il GOTO. Io scrivo
>codice non procedurale da un sacco di tempo (moooolto prima di VB e di
>Windows) e ho sempre usato il GOTO *quando* serviva.
E non è il caso di adeguarsi ai nuovi sistemi?
Il fatto è proprio che il Goto NON serve...
D'altra parte "per scrivere un programma servono solo tre strutture:
assegnazione, selezione (if) e un loop".
Ciao.
Maurizio Borrelli
> > the NET Fury ha scritto
> > se
> > commentato malamente...
Questo non vuol dire essere un purista, quantomeno e' un'interpretazione
personale del concetto di purezza, virtu' relativa.
> > deve essere come un linguaggio parlato! pensa se
> > mentre fai un discorso salti ad un altro, poi esci fuori con tutt'altra
> > cosa
> > quindi un'altra ancora e alla fine non ti ricordi più da dove eri
> > partito!
> > ecco questo è l'uso del GOTO... CMQ ritengo che come utilità allora sia
> > meglio il GOSUB...RETURN, anche se poi bisogna fare ancor più
> > attenzione!
> E perchè lo dici a me che sono completamente d'accordo con te? (a parte la
> storia sul GOSUB, fratello del GOTO)
Credo che Goto abbia senso solo nella gestione degli errori mentre trovo
molto utile Gosub in fase di abbozzo, mentre si sta preparando quella che
diventera' una routine Sub o Function. Credo sia anche utile, ma da evitare
quando possibile, se si vuole avere "sott'occhio" una parte di codice o per
evitare alcune parti ripetitive senza fare una chiamata esterna alla
routine.
> > io ancore specifico l'assegnamento con l'inutile [LET] :) figurati come
> > sono
> > ridotto ;) eheheh
E siamo in due!
> > però ti garantisco che il codice è molto più leggibile!
> Secondo me è più leggibile senza,
Effettivamente non tutti trovano che aumenti la leggibilita'. Alcuni sono
anche presi da crisi isteriche quando vedono un "Let".
> comunque sembra che il LET consenta al
> compilatore di ottimizzare un pochino l'assegnazione poichè capisce al
> volo
> che l'uguale è un'assegnazione e non un confronto: come saprai il basic è
> l'unico linguaggio che usa lo stesso simbolo per assegnazione e confronto,
> il cui significato cambia solo dal contesto.
Che le benedizioni del tuo Dio scendano su di te e la tua famiglia! Ora mi
sento meno rimbambito e meno pedante.
--
Ciao.
Maurizio
the NET Fury
"Zanna" <zntf...@tin.it> ha scritto nel messaggio
news:89qv18$l7k$1...@nslave1.tin.it...
CUT
> Già proprio come il "Hardcore Visual Basic" della Microsoft Press
> (consultabile parzialmente sull'MSDN) dove al capitolo _1_ paragrafo _1_
> "Language Purification" si cita tra le altre cose sul GOTO:
>
> It has its uses, primarily with error traps. Because error handling is
> inherently unstructured, an unstructured feature like Goto fits right in.
If
> you use Goto for any other purpose, however, chances are you're writing
bad
> code. The C version of Goto actually makes some code easier to read as
well
> as more efficient, but that's because C's switch statement is less
powerful
> than Basic's Select Case.
questa è una questione di punti di vista! secondo me C-switch è ben più
potente del select case sotto certi aspetti, anche se poi pecca sotto alcuni
altri...
poi ragazzi ricordiamo che il C ha un operatore ternario che io amo alla
follia pura!
long double rfact(n)
register unsigned char n;
{
return(n>1 ? (long double)(long) n--*rfact(n) : 1.0e0f);
}
sbrodolo ogni volta che la vedo... :)
c'ho massacrato un Prof universitario con questa funzione! credo cha ancora
la debba capire! :)
poi per quanto riguarda il C-break non vedo alcun problema che ne derivi
dall'uso in nidificazione!
> >Non vedo cosa c'entri la programmazione procedurale con il GOTO. Io
scrivo
> >codice non procedurale da un sacco di tempo (moooolto prima di VB e di
> >Windows) e ho sempre usato il GOTO *quando* serviva.
>
> E non è il caso di adeguarsi ai nuovi sistemi?
> Il fatto è proprio che il Goto NON serve...
oddio... se proprio vuoi far correre il più possibile il tuo codice allora
serve, come serve GOSUB RETURN, solo che così facendo torniamo indietro di
una decina d'anni... e per estrapolazione possiamo dire che la
programmazione ad oggetti è uno scherzo della natura da abortire... chi vuol
capire capisca!
> D'altra parte "per scrivere un programma servono solo tre strutture:
> assegnazione, selezione (if) e un loop".
eddaì non esagerare... più roba c'hai a disposizone meglio è!!! :)
facciamo una petizione affinché Bill metta nel VB7 prossimo i puntatori, il
C-union e l'operatore ternario?
così potremmo programmare il VB come fosse il C :))
the NET Fury
"Maurizio Borrelli" <maurizio...@tin.it> ha scritto nel messaggio
news:89r3e9$l15$7...@nslave2.tin.it...
> > "Zanna" ha scritto
> > > the NET Fury ha scritto
> > > io sono un purista del codice, il programma deve essere leggibile
anche
> > > se
> > > commentato malamente...
>
> Questo non vuol dire essere un purista, quantomeno e' un'interpretazione
> personale del concetto di purezza, virtu' relativa.
vebbé dipende da qual punto!
> > > deve essere come un linguaggio parlato! pensa se
> > > mentre fai un discorso salti ad un altro, poi esci fuori con
tutt'altra
> > > cosa
> > > quindi un'altra ancora e alla fine non ti ricordi più da dove eri
> > > partito!
> > > ecco questo è l'uso del GOTO... CMQ ritengo che come utilità allora
sia
> > > meglio il GOSUB...RETURN, anche se poi bisogna fare ancor più
> > > attenzione!
> > E perchè lo dici a me che sono completamente d'accordo con te? (a parte
la
> > storia sul GOSUB, fratello del GOTO)
tanto per dirlo! :)
> Credo che Goto abbia senso solo nella gestione degli errori mentre trovo
> molto utile Gosub in fase di abbozzo, mentre si sta preparando quella che
> diventera' una routine Sub o Function. Credo sia anche utile, ma da
evitare
> quando possibile, se si vuole avere "sott'occhio" una parte di codice o
per
> evitare alcune parti ripetitive senza fare una chiamata esterna alla
> routine.
cioè prima in bozzo (pseudo) usi GoSub, poi lo ritrasfromi in sub o function
?
boh!!!
> > > io ancore specifico l'assegnamento con l'inutile [LET] :) figurati
come
> > > sono
> > > ridotto ;) eheheh
>
> E siamo in due!
oh, bene mi parevo l'unico scemo! :)
> > > però ti garantisco che il codice è molto più leggibile!
> > Secondo me è più leggibile senza,
secondo te... :)
>
> Effettivamente non tutti trovano che aumenti la leggibilita'. Alcuni sono
> anche presi da crisi isteriche quando vedono un "Let".
cazzi loro, io ho le stesse crisi quando non lo trovo!
e lo rimetto dappertutto! :) CTRL+INS CTRL+INS... ufff... son stanco son
stufo!
> > comunque sembra che il LET consenta al
> > compilatore di ottimizzare un pochino l'assegnazione poichè capisce al
> > volo
> > che l'uguale è un'assegnazione e non un confronto: come saprai il basic
è
> > l'unico linguaggio che usa lo stesso simbolo per assegnazione e
confronto,
> > il cui significato cambia solo dal contesto.
>
> Che le benedizioni del tuo Dio scendano su di te e la tua famiglia! Ora mi
> sento meno rimbambito e meno pedante.
questo lo sapevo, CMQ grazie per la riconferma!
Zanna
the NET Fury ha scritto nel messaggio <89r8bh$rqh$1...@nslave2.tin.it>...
>ciao,
>
>"Zanna" <zntf...@tin.it> ha scritto nel messaggio
>news:89qv18$l7k$1...@nslave1.tin.it...
>
>
>poi ragazzi ricordiamo che il C ha un operatore ternario che io amo alla
>follia pura!
Qui devo ammetterlo... nella mia sconfinata ignoranza non ho capito a cosa
ti riferisci con "operatore ternario".
Se intendi il "? :" ce l'ha anche VB č l'IIf() che non ho mai usato e spero
di non farlo mai perchč č riconducibile al piů chiaro If-then-else, e poi
non mi dire che questa roba qui sotto č chiara!
>long double rfact(n)
>register unsigned char n;
>{
> return(n>1 ? (long double)(long) n--*rfact(n) : 1.0e0f);
>}
Ok, č la classica funzione ricorsiva per il calcolo del fattoriale ma uno ci
deve perdere un minuto solo per riuscire a distinguere le varie parti della
funzione.
Invecie del C mi piace parecchio il fatto di poter fare piů operazioni nello
stesso statement del tipo a=(a++=b--) ma anche questa pratica č abbastanza
oppinabile.
>sbrodolo ogni volta che la vedo... :)
>c'ho massacrato un Prof universitario con questa funzione! credo cha ancora
>la debba capire! :)
Appunto... bell'esempio di chiarezza di codice :)
>oddio... se proprio vuoi far correre il piů possibile il tuo codice allora
>serve, come serve GOSUB RETURN,
Emh, non piů... cioč con la compilazione in codice nativo il gosub č 5-6
volte piů lento della chiamata ad una sub, al contrario succede se compili
in P-Code.
Anche questo č un bel mistero.
> solo che cosě facendo torniamo indietro di
>una decina d'anni... e per estrapolazione possiamo dire che la
>programmazione ad oggetti č uno scherzo della natura da abortire... chi
vuol
>capire capisca!
Mah, io sono sempre del parere che fra una decina d'anni si inventeranno la
"programmazione a carciofi" (AOP: Artichoke Oriented Programming) e allora
tutti a programmare con un carciofo al posto del mouse ed ad infierire sullo
stile dei vecchi programmatori che scrivevano secondo le regole della OOP.
:)
>> D'altra parte "per scrivere un programma servono solo tre strutture:
>> assegnazione, selezione (if) e un loop".
>eddaě non esagerare... piů roba c'hai a disposizone meglio č!!! :)
>facciamo una petizione affinché Bill metta nel VB7 prossimo i puntatori, il
>C-union e l'operatore ternario?
Non sarebbe male (almeno per i primi due) se inseriti intelligentemente,
comunque restano sempre indispensabili i soli tre elementi di cui sopra, che
poi siano sotto diverse forme (Case al posto dell'If, Let o = "semplice" o
Set, While o Until o For o che ne so io) ma usi sempre e solo assegnazioni,
condizioni e loop.
>cosě potremmo programmare il VB come fosse il C :))
E allora finalmente mi installerei il C++ che ho qui sullo scaffale a
riempirsi di polvere :)
Ciao
pal
"Zanna" <zntf...@tin.it> ha scritto
> Mah, io sono sempre del parere che fra una decina d'anni si inventeranno
la
> "programmazione a carciofi" (AOP: Artichoke Oriented Programming) e allora
> tutti a programmare con un carciofo al posto del mouse ed ad infierire
sullo
> stile dei vecchi programmatori che scrivevano secondo le regole della OOP.
> :)
mi auguro che almeno sia stato lessato. e non cosparso d'olio o altri lipidi
allo stato brado.
(d'altronde anche il c.d. spaghetti programming prevede oggetti cotti, seno'
e' linearissimo, no?).
Stefano Minardi
>>avere un break - il che poi torna molto utile.)
>
>Proprio un'infinità di volte... ad esempio... dunque... vediamo... mmm....
>boh.
Beh, p.es., in Basic una situazione come questa:
Select Msg
Case WM_MSG1
esegue codice per WM_MSG1
esegue codice come per WM_MSG2
Case WM_MSG2
esegue codice per WM_MSG2
....
End Select
(che a me e a chi ha pensato il select del C capita spesso, immagino non a
te) richiede soluzioni come (a) la replica del codice nei due Case
(bell'esempio di ottimizzazione), (b) un bel Goto dal Case WM_MSG1 a Case
WM_MSG2 (eh eh eh), (c) un bel GOSUB ad una routine magari messa proprio in
fondo al sorgente, (d) una bella chiamata ad una function (ottimizzazione e
chiarezza in un colpo solo).
In C sarebbe:
select(msg)
{
case WM_MSG1:
esegue codice per WM_MSG1
case WM_MSG2:
esegue codice per WM_MSG2
break;
...
}
>E a mettere il codice di ErrQuit in una sub non ci hai mai pensato?
Scusa, ma che me ne faccio di chiamare una Sub se poi devo uscire dalla
routine? Pensi che sia disposto a scrivere:
If Not MyFunc(x,y,z) Then
MiaSub Parm1,Parm2,Parm3...
Exit Function
End If
invece di un innocente:
If Not MyFunc(x,y,z) Then
goto ErrQuit
End If
?
Ci sono svariati motivi: (a) per ogni funzione che non fa quello che mi
aspetto dovrei chiamare quella maledetta Sub; (b) non so necessariamente
cosa fa ErrQuit: a seconda della routine potrebbe chiudere sei o sette
dynaset e/o file aperti nella funzione: te l'immagini chiamare una sub che
fa questo? (ovviamente le variabili andrebbero passate a mani basse); (c) In
questo modo sono sicuro che tutte le eccezioni vengono gestire nello stesso
modo (p.es. vengono chiusi file eventualmente aperti, etc.); (d) In questo
modo io so che un Goto ErrQuit è *sempre* una cosa che ricordo (come il nome
di una funzione) e quindi dominiabile per me; (e) Posso scrivermi un Addin
che mi crea tutte le funzioni del programma con già inclusa una label
"ErrQuit:", che così diventa quasi una parte standard del linguaggio - è un
fatto che in nessuno dei miei programmi si ha un dubbio su come localizzare
un errore, perché tutti i messaggi includono il nome della funzione che ha
generato l'eccezione. O più banalmente: verissimo che l'uso di GOTO sia da
limitare, ma a volto un bel GOTO ti leva d'impiccio. Sono ancora convinto
che alla MS (o chiunque abbia scritto la pagina citata) abbiano presneti
quei sorgenti di GWBasic composti da un'unica interminabile routine zeppa di
GOTO e GOSUB (visto che la colpa era loro...).
>Comunque se il tuo scopo è solo saltare parte del codice mi sembra MOLTO
più
>elegante e lineare scrivere
>
>If Not MyFunc(x,y,z) Then
> [Codice da saltare]
>End if
>[Codice ErrQuit]
Molto elegante, ma solo se la funzione contiene al massimo un test di questo
genere. Se ce ne sono anche solo due o tre viene qualcosa come
>If Not MyFunc(x,y,z) Then
> [Codice da saltare]
>End if
>If Not MyFunc(x,y,z) Then
> [Codice da saltare]
>End if
>If Not MyFunc(x,y,z) Then
> [Codice da saltare]
>End if
>[Codice ErrQuit]
Non è che non abbia mai visto codice così, quello che dico è che se "Codice
da saltare" sono 20 righe di codice, per me il codice non è perspicuo.
Magari va ripensata l'intera rotine, ma perché non usare un Goto ErrQuit,
visto che tutte saltano *ad un'unica label*? Ti sembra poco chiaro che in
una funzione tutte le eccezioni finiscano in un Goto ErrQuit? A me sembra
chiarissimo, proprio come On Error Goto ErrQuit (e dai con il GOTO!).
>E non è il caso di adeguarsi ai nuovi sistemi?
>Il fatto è proprio che il Goto NON serve...
Io non mi sono mai *adeguato* ai nuovi sistemi, ho cercato di *contribuire*
ai nuovi sistemi quando alla Microsoft ritenevano che 64KB fossero un bel
po' di memoria per un linguaggio.
Che significa mettere insieme lo stile del codice con le nuove tecniche di
programmazione? E' chiaro che c'è un punto di intersezione, ma che passi per
il GOTO mi sembra veramente grossa. Mi sa che rischiate di fare di questo
povero GOTO solo un capro espiatorio per altri problemi. Sentir poi dire
(non ho capito se con ironia, ma temo di no) che è meglio codice senza una
riga di commento che con qualche GOTO mi da' un pochino da pensare. Forse
non scriviamo programmi per lo stesso pubblico. Comunque sia, l'impressione
è che se qualche autorità dichiarasse illegittimo l'uso di XOR (in quanto
rappresentabile altrimenti) si dileggerebbe chiunque ne faccia uso, non
perché sia effettivamente stupido o poco economico, ma perché così
dev'essere.
(Sono un pochino risentito, lo ammetto, perché identificare uno che usa GOTO
con una specie di fossile mi pare molto snob e poco realistico. Possiamo
sfidarci a duello e produrre vicendevolmente esempi di codice e relative
applicazioni fino alla soddisfazione di uno dei due. Occhio che sparo meglio
di come scrivo;-)
>D'altra parte "per scrivere un programma servono solo tre strutture:
>assegnazione, selezione (if) e un loop".
In alcuni linguaggi non esistono cicli di loop, che veramente sono superflui
e possono essere raramente ottimizzati.
Stefano Minardi
>dall'uso in nidificazione!
Nel senso che non puoi usare break nello stesso modo in cui VB usa gli
operatori di taglio:
For i = 1 to 10
do
k = k + 1
select case p
case 1:
Exit Do
o magari Exit For
...
end select
loop
next i
In C non puoi usare il break per uscire da una situazione nidificata: torni
solo al livello immediatamente superiore. Percio' un break in una select
significa uscire dalla select, nel loop uscire dal loop, nel for uscire dal
for. IN altre parole, se nel "case 1" del C metti break è perché ce lo devi
mettere e ti serve solo per uscire dal select. Questa è 'purezza' ragazzi!
(Però mi manca il "continue" - altra forma camuffata di goto.)
>oddio... se proprio vuoi far correre il più possibile il tuo codice allora
>serve, come serve GOSUB RETURN, solo che così facendo torniamo indietro di
>una decina d'anni... e per estrapolazione possiamo dire che la
>programmazione ad oggetti è uno scherzo della natura da abortire... chi
vuol
>capire capisca!
E daie! Ma cos'è questa storia del GOTO e delle lontane tecniche di
programmazione? Dieci anni fa il GOTO era screditato come adesso e 15 anni
fa c'erano linguaggi non procedurali che consentivano il multitasking quando
alla Microsoft sviluppavano ancora il Basic per la Commodore e Xerox e Apple
si contendevano senza avversari il mondo Windows. Non è che ora, perché
avete uno straccio di linguaggio come VB, potete fare gli schizzinosi.
PS: fra l'altro, in VB esiste effettivamente l'operatore IIF che (invece) io
trovo molto comodo in sostituzione di
IF/THEN/ELSE - p.es.:
If bType Then
chkCheck.Value=vbChecked
Else
chkCheck.Value=vbUnchecked
Endif
non mi pare più bello e leggibile di:
chkCheck.Value = IIF(bType, vbChecked, vbUnchecked)
Se non si usa IIF si rischia di tornare indietro di un milione di anni !-)
Roberto Piazzolla
"Maurizio Borrelli" <maurizio...@tin.it> ha scritto nel messaggio
news:89r3e9$l15$7...@nslave2.tin.it...
> trovo molto utile Gosub in fase di abbozzo, mentre si sta preparando
quella che
> diventera' una routine Sub o Function. Credo sia anche utile, ma da
evitare
> quando possibile, se si vuole avere "sott'occhio" una parte di codice o
per
> evitare alcune parti ripetitive senza fare una chiamata esterna alla
> routine.
La penso/avo anche io come te. La scorsa estate avevo postato un messaggio
sul newsgroup chiedendo se il Gosub si poteva ancora usare e ne era
scaturito un bel thread di messaggi.
Comunque alla fine il problema maggiore del gosub č che č lentissimo nel
codice compilato. Cioč, nell'IDE o compilando in pseudo codice č + veloce
della chiamata a funzione, mentre nel compilato finale č decisamente +
lento. Ricordo che erano state fatte tutte le prove del caso, mi pare fosse
stato Roal a farle, ma non vorrei sbagliarmi e non ho + il messaggio
originale.
Resto comunque d'accordo con te sulla filosofia. Se ti serve una funzione
che venga chiamata piů volte solo all'interno di una unica procedura, č piů
leggibile il gosub. Questione di gusti, ovviamente, non vorrei che Zanna mi
mordesse per questa mia affermazione. 8-)
Ciao
*Roby*
Zanna
Roberto Piazzolla ha scritto nel messaggio <89th8j$g8h$4...@nslave1.tin.it>...
>
>Questione di gusti, ovviamente, non vorrei che Zanna mi
>mordesse per questa mia affermazione. 8-)
Basta, ho deciso di non mordere più nessuno.
Mi sto rendendo conto che nel NG ultimamente (anche a causa mia, dev'essere
l'influenza -spero passeggera- di qualche cattiva stella) ci sono degli
atriti ed anzichè aiutarci ci stiamo scannando a vicenda.
Poi chi legge i messaggi (mi ci metto sempre anch'io) se la prende sempre in
modo personale.
Che ognuno scriva come preferisce, d'altra parte ognuno ha esigenze diverse.
Se poi uno mette ancora i numeri di linea nel codice (lo suggerisce
addirittura il libro -consultabile su MSDN- Advanced Microsoft Visual Basic
5 della Microsoft Press. Ho letto cose allucinanti in questo libro) che
faccia pure. Peccato che VB non supporti la keyword asm, come il delphi, per
poter scrivere codice assembly...
Ciao
P.S.: Il gosub l'ho sempre trovato scomodo anche in Basic e le riserve su di
lui sono le stesse che sul Goto, anzi pote- hem- DOVEndo scegliere userei il
goto.
Quando scrivevi in besic ho solo usato il Goto, ma io sono passato
direttamente dal vecchio M$Dos per home computer al pascal e poi a C e VB,
saltando il QBasic.
Roberto Piazzolla
"Zanna" <zntf...@tin.it> ha scritto nel messaggio
news:89tm2r$35b$1...@nslave2.tin.it...
> Basta, ho deciso di non mordere più nessuno.
> Se poi uno mette ancora i numeri di linea nel codice (lo suggerisce
> addirittura il libro -consultabile su MSDN- Advanced Microsoft Visual
Basic
> 5 della Microsoft Press. Ho letto cose allucinanti in questo libro)
E' quello che dice anche di usare sempre le variant?
Comunque i numeri di linea sarebbero comodi per visualizzare ila posizione
in cui è avvenuto l'errore, se non altro durante la fase di debug del
programma. Purtroppo l'oggetto ERR non gestisce più la proprietà Line (e non
dire che questo non sarebbe comodo 8-)).
> Peccato che VB non supporti la keyword asm, come il delphi, per
> poter scrivere codice assembly...
A me piacerebbe. Finora ho lavorato principalmente in 3 liguaggi.: VB, ASM e
Clipper. E l'Asm è forse quello che ho usato di +.
> P.S.: Il gosub l'ho sempre trovato scomodo anche in Basic e le riserve su
di
> lui sono le stesse che sul Goto, anzi pote- hem- DOVEndo scegliere userei
il
> goto.
Beh, Goto e Gosub non sono intercambiabili. Il secondo veniva usato come
chiamata a funzione quando le funzioni non erano disponibili. Per simularlo,
di goto ne servono 2.
Comunque hai ragione, ormai è un retaggio del passato. Però è difficile
disabituarsi ad utilizzare le cose che una volta sembravano il massimo della
comodità.
Ciao
*Roby*
the NET Fury
"Zanna" <zntf...@tin.it> ha scritto nel messaggio
news:89rpe2$hq9$1...@nslave2.tin.it...
>
> the NET Fury ha scritto nel messaggio <89r8bh$rqh$1...@nslave2.tin.it>...
> >ciao,
> >
> >"Zanna" <zntf...@tin.it> ha scritto nel messaggio
> >news:89qv18$l7k$1...@nslave1.tin.it...
> >
> >
> >poi ragazzi ricordiamo che il C ha un operatore ternario che io amo alla
> >follia pura!
>
> Qui devo ammetterlo... nella mia sconfinata ignoranza non ho capito a cosa
> ti riferisci con "operatore ternario".
> Se intendi il "? :" ce l'ha anche VB è l'IIf() che non ho mai usato e
spero
> di non farlo mai perchè è riconducibile al più chiaro If-then-else, e poi
> non mi dire che questa roba qui sotto è chiara!
ESATTO... me l'ero scordato l'IFF :)
l'IFF quando usato è molto lento, se non ricordo male è più veloce usare un
IF-THEN-ELSE, CMQ è vero che con IFF guadagni molta leggibilità!
>
> >long double rfact(n)
> >register unsigned char n;
> >{
> > return(n>1 ? (long double)(long) n--*rfact(n) : 1.0e0f);
> >}
>
>
> Ok, è la classica funzione ricorsiva per il calcolo del fattoriale ma uno
ci
> deve perdere un minuto solo per riuscire a distinguere le varie parti
della
> funzione.
esagerato, già il nome della funzione la dice lunga :)
CMQ un prof universatario asseriva che non era possibile funzionasse perché
lui sui libri non ha mai visto la funzione sintetizzata in sola riga di
codice... che uomo ignorante e privo di immaginazione!!! immaginati la
faccia quando l'ha provato! :)
> Invecie del C mi piace parecchio il fatto di poter fare più operazioni
nello
> stesso statement del tipo a=(a++=b--) ma anche questa pratica è abbastanza
> oppinabile.
un corno opinabile... è un'altra di quelle cose che mi mancano tanto in VB
:(
> >sbrodolo ogni volta che la vedo... :)
> >c'ho massacrato un Prof universitario con questa funzione! credo cha
ancora
> >la debba capire! :)
>
> Appunto... bell'esempio di chiarezza di codice :)
ohé, guarda che se capisci il C + chiaro e ottimizzato di così si muore! :)
> >oddio... se proprio vuoi far correre il più possibile il tuo codice
allora
> >serve, come serve GOSUB RETURN,
>
> Emh, non più... cioè con la compilazione in codice nativo il gosub è 5-6
> volte più lento della chiamata ad una sub, al contrario succede se compili
> in P-Code.
> Anche questo è un bel mistero.
non lo sapevo, CMQ non lo adopero dai tempi di QB e VBDOS.
però ewra carino quel ON valx GOSUB 10,20,30,40,50,60 eheheh un bel modo di
simulare il SELECT CASE,
effettivamente anche col vecchio BASIC si riusciva tramite alcuni
stratagemmi e vecchie operazioni a simulare un po' tutto del VB. :)
> > solo che così facendo torniamo indietro di
> >una decina d'anni... e per estrapolazione possiamo dire che la
> >programmazione ad oggetti è uno scherzo della natura da abortire... chi
> vuol
> >capire capisca!
>
> Mah, io sono sempre del parere che fra una decina d'anni si inventeranno
la
> "programmazione a carciofi" (AOP: Artichoke Oriented Programming) e allora
> tutti a programmare con un carciofo al posto del mouse ed ad infierire
sullo
> stile dei vecchi programmatori che scrivevano secondo le regole della OOP.
> :)
ahahahahah... tra poco non programmeremo più, descriveremo solo il
problema...
> >> D'altra parte "per scrivere un programma servono solo tre strutture:
> >> assegnazione, selezione (if) e un loop".
>
> >eddaì non esagerare... più roba c'hai a disposizone meglio è!!! :)
> >facciamo una petizione affinché Bill metta nel VB7 prossimo i puntatori,
il
> >C-union e l'operatore ternario?
>
> Non sarebbe male (almeno per i primi due) se inseriti intelligentemente,
> comunque restano sempre indispensabili i soli tre elementi di cui sopra,
che
> poi siano sotto diverse forme (Case al posto dell'If, Let o = "semplice" o
> Set, While o Until o For o che ne so io) ma usi sempre e solo
assegnazioni,
> condizioni e loop.
>
> >così potremmo programmare il VB come fosse il C :))
>
> E allora finalmente mi installerei il C++ che ho qui sullo scaffale a
> riempirsi di polvere :)
io ho VS, però trovo ostica l'interfaccia e la costrizione ad usare API del
C, una volta col DOS usavo QC2.5, QCX (del MSC Compiler) e me la cavavo (ho
anche scritto un manule :) mai pubblicato)... la programmazione ad oggetti
la conosco nel concetto, applicat sommariamente con VB e le sue classi che
pià che oggetti sono oggettini :)
---
Faber
>
>l'IFF quando usato è molto lento, se non ricordo male è più veloce usare un
>IF-THEN-ELSE, CMQ è vero che con IFF guadagni molta leggibilità!
io uso molto spesso IIf... sicuro che è molto lento? per informazione...
grazzzzz
Faber
Maurizio Borrelli
Qui dice che IIf e' tre volte piu' lenta:
http://www.vb2themax.com/Item.asp?PageID=TipBank&ID=122
Sarebbe interessante pero' valutare la somma di tutte le istruzioni
necessarie per ottenere lo stesso scopo:
A)
Dim a, b, c, d, e
Let a = espressione
Let c = espressione
Let d = espressione
If a Then Let b = c Else Let b = d
Let e = Calcola(b)
B)
Dim a, c, d, e
Let a = espressione
Let c = espressione
Let d = espressione
Let e = Calcola(IIf(a, c, d))
--
Ciao.
Maurizio
the NET Fury
"Maurizio Borrelli" <maurizio...@tin.it> ha scritto nel messaggio
news:8a7sk3$2d1$1...@nslave1.tin.it...
> > > "Faber"
> > > ESATTO... me l'ero scordato l'IFF :)
> > > l'IFF quando usato è molto lento, se non ricordo male è più veloce
usare
> > > un IF-THEN-ELSE, CMQ è vero che con IFF guadagni molta leggibilità!
> > io uso molto spesso IIf... sicuro che è molto lento? per informazione...
>
> Qui dice che IIf e' tre volte piu' lenta:
> http://www.vb2themax.com/Item.asp?PageID=TipBank&ID=122
>
lo sapevo anch'io e per aver semplicemente letto il manuale, mi pare sulla
parte dove parla di come ottimizzare il codice... praticamente hanno messo
un'istruzione bella che però sconsigliano in quanto molto lenta... bah, chi
ci capisce è bravo, e proprio non riesco a capire come faccia ad esser lenta
visto che è stata creata per gestire una caso specifico di IF/THEN/ELSE...
secondo me alla Microsoft quando hanno scritto il codice della IFF il
programmatore non dormiva da una settimana! :)
per fare le prove che hai postato basta che usi un loop molto lungo e fai
analizzare i risultati dal Code Profiler!
Faber
>analizzare i risultati dal Code Profiler!
grazissimo per questo consiglio, era proprio ciň di cui avevo bisogno.
un'altra cosa perň di cui avrei bisogno č.... uhmmm.... cos'č il Code
Profile? :) č un programma, lo posso scaricare da qualche parte?
grazie!!!!!!
Faber
Maurizio Borrelli
> > "Maurizio Borrelli"
[snip]
> > Effettivamente non tutti trovano che aumenti la leggibilita'. Alcuni
> > sono anche presi da crisi isteriche quando vedono un "Let".
> cazzi loro, io ho le stesse crisi quando non lo trovo!
> e lo rimetto dappertutto! :) CTRL+INS CTRL+INS... ufff... son stanco son
> stufo!
Trovo piu' riposante SHIFT+INS.
--
Ciao.
Maurizio
the NET Fury
"Maurizio Borrelli" <maurizio...@tin.it> ha scritto nel messaggio
news:8a854i$ggj$1...@nslave1.tin.it...
:) oops, scusa ho sbagliato...
ovvio che CTRL+INS serve per copiare e SHIFT+INS per incollare, mentre
SHIFT+DEL per tagliare :)
Maurizio Borrelli
[...]
> ahahahahah... tra poco non programmeremo più, descriveremo solo il
> problema...
Visto come, mediamente, sono descritti i problemi nelle conversazioni da ng
c'e' da tremare all'idea.
--
Ciao.
Maurizio
Franco Languasco
mi ha incuriosito.
Ho misurato, con mio vecchio programma per valutare la velocita' del codice, le seguenti
due versioni:
Static a As Boolean
a = IIf(a, False, True)
e:
Static a As Boolean
If a Then
a = False
Else
a = True
End If
con i risultati:
IF 0.325 [microsecondi] piu'/meno 0.002 [microsecondi] al 95% di confidenza.
IIF 2.151 [microsecondi] piu'/meno 0.005 [microsecondi] al 95% di confidenza.
L' IIF risulterebbe circa sette volte piu' lento dell' IF.
Ho provato con un PC con Pentium III a 500 [MHz] sotto Windows NT4.
Saluti a tutti.
Franco
the NET Fury
"Franco Languasco" <MC7...@MCLINK.IT> ha scritto nel messaggio
news:38CA5678...@MCLINK.IT...
> Ho misurato, con mio vecchio programma per valutare la velocita' del
codice, le seguenti
> due versioni:
>
CUT
> con i risultati:
> IF 0.325 [microsecondi]
> IIF 2.151 [microsecondi]
>
> L' IIF risulterebbe circa sette volte piu' lento dell' IF.
> Ho provato con un PC con Pentium III a 500 [MHz] sotto Windows NT4.
grazie della conferma...
come dicevo una cosa simile è oltremodo scandalosa!
sono sempre più convinto che quando hanno realizzato questa funzione il
programmatore o non dormiva da una settimana o era ubriaco, o indaffarato
con la figlia del principale :)
trovo assurdo scrivere una routine ottimizzata per fare un lavoro specifico
che sia più lenta della routine GeneralPurpose !!! SCANDALOSO!!!
è ovvio che la IFF aumenta la leggibilità di molto, ma non va assolutamente
usata in routines time-critical
>
> the NET Fury wrote:
>
> > l'IFF quando usato è molto lento, se non ricordo male è più veloce usare
un
> > IF-THEN-ELSE, CMQ è vero che con IFF guadagni molta leggibilità!
---
the NET Fury
"Faber" <zann...@libero.it> ha scritto nel messaggio
news:8a7vv3$jco$1...@nslave1.tin.it...
> >per fare le prove che hai postato basta che usi un loop molto lungo e fai
> >analizzare i risultati dal Code Profiler!
>
> grazissimo per questo consiglio, era proprio ciò di cui avevo bisogno.
> un'altra cosa però di cui avrei bisogno è.... uhmmm.... cos'è il Code
> Profile? :) è un programma, lo posso scaricare da qualche parte?
> grazie!!!!!!
cerca o sull'HD o sul CDROM di VB4 (mi pare che col 5 o 6 non ci fosse più)
il programma VBCP32.EXE,
eseguilo, poi esegui il VB, da quel momento in poi lo potrai usare quando
vuoi in quanto dovresti trovarlo tra le aggiunte! per l'uso c'è il wizard...
è molto semplice, puoi monitorare le singole procedure e tante altre cose
interessanti!
Stefano Minardi
>usata in routines time-critical
Forse nelle routine time-critical sarebbe bene non usare nessuna delle
istruzioni di VB.