Newsgroup: it.comp.lang.visual-basic
Titolo: Visual Basic vs Delphi

Salve a tutti,
come da oggetto vorrei conoscere pregi e difetti di VB e Delphi,
quindi mi piacerebbe che gli utilizzatori di questi linguaggi
facessero un confronto, cercando di stabilire quale dei due ha
l'ambiente di sviluppo migliore, qual è il più efficiente, quale +
facile da apprendere, con quale dei 2 la "manutenzione" del codice
risulta più semplice etc etc
Perdonatemi il cross-post, l'ho fatto per dare maggiore obiettività al
thread   ;-) , se potete mantenetelo.
Aspetto numerose risposte.
Lupin 
hpage: 
http://i.am/eugenio
 ---> 
www.agonet.it/~eugenio.t
   visitala!!!
Rimuovere XXX per rispondere via email

etc etc
delphi

delphi
Ok, ma anche VB se spremuto per bene sa raggiungere ottimi risultati (a
volte più di delphi).
Ovviamente serve conoscerlo un po', non bastano 3 mesi d'esperienza...
C'è una cosa da dire: Delphi è molto schizzinoso sulle differenze di tipi di
dati nelle assegnazioni.
Se con VB puoi fare
    NumLong& = txtNumero.Text
in Delphi sei costretto ad andare via di casting e conversioni esplicite
    NumLong = strtoint(txtNumero.Text)
e questa è una situazione molto fortunata.
Questo evita alcuni bug, ma conporta un codice meno leggibile.
Delphi inoltre compila tutto il prog in un unico exe, quindi nessuna dll
aggiuntiva o ocx o quant'altro.
Il che da una parte è un bene, ma quando aggiorni un componente devi
ricompilare tutto il prog e ridistribuire il tutto.
Io programmo sia in VB che in Delphi e capita che mentre lavoro in D mi
venga da dire "se lavorassi in VB questo si potrebbe fare..." e viceversa.
Se il tuo obbiettivo è la semplicità VB è la risposta.
Se cerchi prestazioni la risposta è D.
Ciao.

Se cerchi prestazioni la risposta è D.
Secondo la mia modesta opinione e' sempre meglio delphi,
richiede un po piu' di tempo (neanche molto) ma ripaga
ampiamente dello sforzo.
Cordiali saluti
Carlo

ampiamente dello sforzo.
Tu sei un programmatore vecchio stile, vero?
A me piace programmare con linearità, chiarezza nel codice e variabili
giuste al posto giusto (spesso con il loro prefisso stile C), ma VB è
davvero molto comodo a volte...
Però effettivamente delphi permette alcune cosette (in quanto compila
VERAMENTE) che VB non può.
Ai posteri l'ardua sentenza...

etc etc
Delphi e' ottimo per generare eseguibili SENZA DLL.
Delphi e' ottimo per fare LE DLL.
Delphi ha tutte le API dichiarate...
Mi spiace ma non mi viene niente con VB....
Ciao
Roberto

con quale dei 2 la "manutenzione" del codice risulta più semplice
Delphi (chiaramente, a parita' di professionalita' del programmatore)
Inoltre:
Entrambi hanno una sintassi (pascal e basic) piuttosto semplice da imparare
Delphi e' un linguaggio ad oggetti, VB non completamente.
Entrambi sono ambienti RAD (Rapid Application Development), personalmente
preferisco l'ambiente di Delphi.
Espandibilita' (componenti aggiuntivi, etc...):
Delphi e' imbattibile, i componenti (anche i controlli visuali, textbox,
etc...) sono SCRITTI in Delphi, sono pienamente espandibili (grazie
all'ereditarieta' della programmazione ad oggetti) ed e' possibile crearne
di nuovi (questo presuppone una certa capacita' ed esperienza, ma non e'
difficilissimo).
VB e' intrinsecamente legato agli OCX (file esterni che poi vanno
distribuiti con l'applicazione, brutto!). Con le nuove versioni di VB e'
possibile creare OCX (la difficolta' e' circa al livello di creazione dei
componenti di Delphi).
Per quanto riguarda la gestione di database:
VB ha a disposizione DAO (o ADO, nell'ultima versione), che e' la tecnologia
Microsoft di accesso ai dati. DAO e' basato sul motore di Access, quindi
accede in modo nativo (leggi veloce) ai db Access. Puo' accedere via ODBC a
qualsiasi db che abbia driver ODBC.
Delphi (come C++Builder) usa il BDE, che e' il motore database di Borland.
Accede in modo nativo a db Paradox. Ha la possibilita' di usare DAO (come
VB) per accedere ad Access. Sono disponibili driver nativi per accedere a
database relazionali client/server (es. Interbase). Infine, puo' usare ODBC.
Prestazioni dei programmi prodotti:
VB, anche compilando in modo nativo, ha seri problemi di performance (dovuti
alle limitazioni intrinseche nell'architettura interna, al garbage collector
e altro).
I programmi fatti con Delphi hanno performance ottimali (il codice binario
prodotto e' della stessa qualita' ottenibile con i migliori compilatori C,
infatti Delphi ha lo stesso compilatore del C++Builder).
Disponibilita' di materiale (sorgenti, componenti aggiuntivi):
direi che i due prodotti si equivalgono, per entrambi e' disponibile
moltissimo materiale in internet (per Delphi esistono siti con migliaia di
componenti spesso utilissimi, per VB lo stesso con sorgenti e OCX).
Per quanto riguarda componenti commerciali, lo stesso...
Inoltre, Delphi puo' utilizzare anche gli OCX, quindi quasi tutto quello che
e' disponibile per VB e' anche utilizzabile con Delphi.
Diffusione:
VB e' molto piu' diffuso di Delphi (anche a livello professionale), ma piu'
che altro per questioni commerciali, non certo per meriti tecnici.
Microsoft ha molto piu' potere commerciale di Inprise, quindi riesce a
"spingere" maggiormente i propri prodotti, tra i quali VB.
Mondo del lavoro:
qui la situazione e' favorevole a VB (anche se dipende dai campi di
utilizzo).
C'e' molta richiesta per programmatori VB, perche' ce ne sono di piu' (VB e'
"apparentemente" piu' semplice da imparare), quindi costano meno alle
aziende.
Mi fermo qui perche' mi si e' grippata la tastiera ;-)
Se hai qualche punto particolare su cui vuoi discutere Delphi/VB, chiedi
pure.
--
Roal Zanazzi
z...@iol.it

codice in VB e' 40 volte piu lento.
Guarda caso ho fatto la stessa cosa (oggi)... ma _molto_ piu' semplice... un
semplice checksum.
Il mio checksum mi va gia' bene, ma un CRC32 e' senz'altro mejo; saresti
disposto a farmi avere la tua funzione (jn delphi) per il CRC32? La devo
piazzare giusto giusto nella DLL usata dal WebWizard.
Ciao
By -MES-   Maronese Ettore
http://ilmes.freeweb.org
(con OCX per stampare i recordset)
Sito Comune di programmatori Visual Basic
http://members.xoom.com/it_lang_vb

infatti Delphi ha lo stesso compilatore del C++Builder).
Beh, le cose non sono cosi' tragiche: nella directory del VB c'e' il
C2.EXE che e' il compilatore del C++ (la parte che traduce in codice
macchina) che l'IDE chiama con il parametro -basic.
Non ho provato, ma se fai un crivello di Eratostene in VC++ ed in VB le
prestazioni dovrebbero essere simili.
Ciao
Gian Michele Bertoni
P.S. Comunque mi e' piaciuta l'analisi!
--
Home Page: 
http://space.tin.it/computer/gbertoni/

Ai posteri l'ardua sentenza...
auguri ai posteri allora !
Ciao
Carlo


Grazie a te e agli altri per le analisi moIto dettagliate; in effetti
mi piacerebbe approfondire l'arogomento "mondo del lavoro": il fatto
che sia molto piů diffuso VB da cosa dipende? 
Quando dici che i programmatori VB "costano meno alle aziende" intendi
dire che mediamente un programmatore Delphi si fa pagare di piů?
In quali campi di utilizzo č piů richiesto Delphi/VB?
Anche in un annuncio di lavoro che ho letto di recente (cercavano il
webmaster per un sito) veniva richiesta la conoscenza di VB, a che
pro? E' cosě utilizzato anche per fare i CGI?


In quali campi di utilizzo č piů richiesto Delphi/VB?
dove c'e' maggior offerta=concorrenza il costo e' minore. Se i risultati,
dal punto di vista dell'imprenditore, sono simili, tra VB e Delphi, e il
programmatore VB (scelto tra una rosa di 50 candidati) costa la meta' di un
analogo programmatore Delphi (scelto tra una rosa di 5), e' ovvio che
l'imprenditore scegliera' il meno peggio tra i programmatori VB no?
Ciao!.. Sandro

Ai posteri l'ardua sentenza...
Chi volete che vinca... Microsoft, come sempre (purtroppo).
--
Roal Zanazzi
z...@iol.it

codice in VB e' 40 volte piu lento.
In media a parita' di algoritmo VB e' dalle 20 alle 50 volte piu' LENTO di
Delphi (la situazione migliora, ma non molto, compilando in nativo con VB).
--
Roal Zanazzi
z...@iol.it

prestazioni dovrebbero essere simili.
Ah, ah, ah... ottimista sognatore! :-)
Prova e poi mi saprai dire...
(poi te lo compilo in C++Builder e vediamo anche li' la differenza ;-)
--
Roal Zanazzi
z...@iol.it

E' così utilizzato anche per fare i CGI?
Non direi...
Sono sicuro che la maggior parte dei CGI e' tuttora scritta in C.
Inoltre, scrivere un CGI in VB e' come usare un martello pneumatico per
aprire una noce (pensa a 2MB di DLL di runtime e OCX vari per un CGI che
scritto in C magari e' di 200KB...)
--
Roal Zanazzi
z...@iol.it

 Aspetto numerose risposte.
La mia esperienza personale nel campo dei linguaggi e' la seguente:
1)basic con lo zx spectrum 16k ,assembler z80 con zx spectrum
16k,Superbasic con Sinclair QL 128K,Assembler 68008 con Sinclair QL 128K,
Pascal standard su mainframe, Fortran, GWBasic, Turbo Pascal 4.0, C, Turbo
Pascal 5,5.5,6 con turbo vision, 7, Borland c++ 3.1,4.1,4.5 e ...DELPHI
1,2,3,4
Ero arrivato a fare i programmi in DOS protected mode, programmavo metà in
c++ e metà in Borland Pascal. Era venuto il momento di passare sotto a
windows ed esisteva il Visual Basic, semplice da usare ma abituato a
programmare nei linguaggi sopra descritti ne valeva anche del mio onore
:-).
Visual Basic non mi ispirava, ero un tipo abituato a scrivere codice ancora
con un editor esterno.. e a vedere tutto il codice, in Visual Basic perdevo
il controllo del sistema...
Borland aveva il pascal per Windows e il c++ per Windows ma passare a
windows era molto stressante, tutte quelle funzioni strane... il codice
diventava una cosa abbastanza incomprensibile (Ad esempio odio tutte le
definizioni di windows scritte in maiuscolo, i typedef..).
Ho temporeggiato.. poi c'e stato l'annuncio di Delphi ed era veramanente
semplice come un visual basic,  e era la naturale evoluzione del Pascal che
conoscevo, dunque il passaggio a Delphi e' stato naturale, ma non semplice
come tutte le cose nuove. Ora avevo un linguaggio potente e visuale con il
controllo del codice, con i sorgenti della VCL e velocissimo a compilare.
Arrivando dalla programmazione a oggetti dove gli oggetti si scrivevano e
non si prendevano semplicemnte dalla toolbar ho continuato a programmare ad
oggetti pur sapendo che non occorre conoscerli per lavorare in Delphi.
Dunque la scelta di Delphi e' stata naturale, Invece ci sono più
programmatori VB perche' VB e' uscito prima e perche' si cominciava a
lavorare in Excel, e poi aver bisogno di piu' e prendere VB.
Per fare gestionali semplici  credo che VB sia ottimo ma se il target e' un
software tecnico, o strutturalmente avanzato VB fallisce.
Ma oggi vale la pena un confronto tra i due linguaggi o occorre considerare
qualche linguaggio nuovo: JAVA.
Oppure invece di JAVA occorre considerare bene CORBA e DCOM, SQL Server,
MTS, VisiBroker.... in quest'ottica il linguaggio "puro" assume aspetti
meno rilevanti diventanto quasi un client il linguaggio stesso.
   Qexxis as Matteo Tosato  
gru...@keycomm.it
 

 Delphi senza meno. Ho scritto proprio oggi una routine che fa il CRC32
Cosa sarebbe questo CRC32?
--
saluti e grazie

che sia molto più diffuso VB da cosa dipende?
A parer mio dipende soprattutto dal fatto che le persone che decidono
all'interno delle aziende generalmente hanno del computer una conoscenza
pari a quella del mio criceto... :-) scherzi a parte, generalmente chi
decide usa il computer al massimo per scrivere delle lettere (quando non
glie lo fa una segretaria generalmente giovane, carina, e con minigonna che
neanche la ferrari ce l'ha così corta), cioè usa, sempre generalmente,
prodotti provenienti da Zio Bill, quindi quando c'è da sviluppare un
programma la prima cosa che pensa è il linguaggio di sviluppo made in M$,
seguendo quindi la massa (generalmente composta da gente come lui...) che si
comporta allo stesso modo... peccato che quantità non vuol dire quasi mai
qualità, ma fà niente...
Ovviamente però quando poi ti ritrovi di fronte ai problemi di
programmazione (per esperienza personale - avendoli provati entrambi - posso
dire che sono stati di gran lunga maggiori con VB che con delphi, o quanto
meno di più difficile soluzione - quando sviluppi un programma e vorresti un
componente che non hai, è molto più facile derivartene uno dai sorgenti di
delphi che non cercare un ocx che ti vada bene e doverlo poi distribuire e
registrare assieme al tuo programma in VB... - però è anche possibile che
sia stato particolarmente jellato io) è il programmatore che deve pensare a
sbrogliarli, perchè chi lo ha assunto vuole il prodotto finito...
Per quanto mi riguarda io sono riuscito a imporre delphi in ditta (circa un
anno fa) e ora sono tutti molto felici di avermi dato retta...
by Phelipe de Sterlich
ELCO - Sistemi Gestione del Tempo
- 
http://www2.cyberforli.it/elco
 -
- 
el...@mbox.cyberforli.it
 -


E' un algoritmo che combina tutti i bytes di un file in una DWord (4
bytes).
Se due files hanno CRC uguali, sono molto probabilmente uguali (1
probabilita' su  4 miliardi che non sia cosi'). Se hanno CRC diversi,
sono sicuramente diversi.
Ciao

Salve a tutti,
[snap]
Wo, che thread!
Carino constatare che quasi tutti i VBcisti del NG pendono più per Delphi
che per VB...
Comunque, volevo rispondere in particolare a Roal.
[io]
però e' molto più comodo che dover riavviare l'app e tornare nella stessa
condizione ogni volta che si cambia una virgola nel codice...
[Roal]
OK, su questo punto VB e' piu' comodo di Delphi (anche se, considerando
l'elevata velocita' di compilazione di Delphi, non ci si mette molto a fare
stop, modifica sorgente, ricompila e run).
Vero, il difficile è tornare nel punto e nella condizione di quando hai
interrotto l'esecuzione.
[R]
Quando devi sviluppare certe applicazioni (soprattutto se critiche o
super-ottimizzate) seguire il flusso del programma in linguaggio assembler
e' decisamente utile.
Mi piacerebbe proprio imparare l'assembly ( :) ), fortunatamente non ne ho
bisogno.
[R]
6) altre cosette come breakpoint attivati ogni N passaggi...
A che serve sapere quante volte si è passati da lì? Non è più utile sapere
il perchè?
(Io lavoro con D 2.0, forse presto passerò al 4, e il debug in Delphi per me
è uno stress, forse perchè sono abituato con VB, poichè quando usavo TPascal
5.5 mi trovavo bene...
O forse c'è qualche trucchetto che non conosco...
[R]
la manutenzione risulta in generale piu' semplice
con delphi grazie al fatto che i sorgenti di delhi
sono enormemente piu' compatti di quelli di vb.
questa caratteristica di delphi permette di generare
programmi non solo piu' manutenibili ma piu' sicuri,
piu' facilmente testabili ecc ecc...
Qui parli sempre del debug ASM? Perchè altrimenti non capirei l'importanza
della dimensione dell'eseguibile nella manutenzione del codice.
[R]
E non dimentichiamo che delphi e' un VERO linguaggio ad oggetti
Vero, ma a quanti secondo te importa questa sottile distinzione? Molti sono
addirittura convinti che VB sia del tutto un linguaggio ad oggetti.
Sai una cosa che mi piace di delphi, ma che allo stesso tempo mi spaventa?
La possibilità di assegnare una qualsiasi procedura (con la sintassi giusta)
ad un evento, il che svincola dal doversi legare sempre e per forza al
"Text1_Change". Questa cosa però mi sembra un po' forviante, poichè non si
sa mai cosa cercare per un evento.
Altra cosa che odio di Delphi è che non posso caricare e scaricare i form a
mio piacimento come avviene in VB.
Per farlo devo fare dei giri di codice un tantino allucinanti.
[R]
WOW... le API si usano anche in Delphi (ed in modo piu' "trasparente"
rispetto a VB.
Comunque non ho MAI (assolutamente MAI) visto programmi che scritti in VB
fossero piu' performanti piuttosto che scritti in Delphi (ripeto: MAI!).
Ok, mi arrendo, almeno sul punto velocità, però le API in delphi non sono
così trasparenti: forse sono io un po' sfigato però mi è capitato di usare
api con lo stesso nome di metodi o procedure già definite, e allora sono
stato costretto a ridefinirle.
Poi, la tanto denigrata incapacità di VB di usare i puntatori (usando solo
var. di tipo Long al loro posto come parametri per le API), qualche volta in
VB mi hanno salvato, perchè D proprio non voleva saperne di farmi funzionare
L'ape con i parametri del tipo giusto (mi riferisco in particolare a
LoadIcon(), per ricavare l'handle di un'icona di sistema)
[R]
Se anziche' scrivere NumLong& ti sbagli e scrivi NumLong cosa
succede ?
[io]
Niente la & l'ho messa solo per far capire che la variabile era di tipo
Long
[R]
Succede che in VB hai dichiarato una variabile di tipo Variant (tipo di
default, occupazione: 16bytes, orribile!)
No, perchè io prima gli ho detto Dim NumLong As Long (sempre, odio i
variant! Sto combattendo anche per questo in un'altro thread, se anche a te
da fastidio sprecare 16bytes in più (magari fosse 16B e basta), continua ad
aiutarmi
nella lotta contro chi sostiene che ormai 16Bytes in più o in meno non fanno
differenza)
Però anche D ha il tipo variant (che non ho ancora avuto luogo di usare).
[io]
Quante volte ti è capitato in delphi di dover fare un cast del tipo
Application.MessageBox(PChar('Messaggio #' + numtostr(lNum)), [...])
veramente fastidioso.
[R]
Mah, e' questione di abitudine... in C++ a volte e' anche peggio.
Inoltre non sempre la "conversione implicita" e' un bene, poiche' richiede
codice macchina aggiuntivo sul quale il programmatore non ha alcun
controllo.
Vero, però ho letto su un'autorevole rivista del settore che a volte (strano
ma vero, io sono rimato allibito, in quanto se possibile anche in VB uso la
conversione esplicita, almeno tra numeri e stringhe e viceversa) è più lenta
(in VB) la conv. espl.. Es: txtNumero.Text = 123 è più veloce di
txtNumero.Text = CStr(123).
Non c'è più religione!
[R]
Anche VB dalla versione 5 COMPILA VERAMENTE.
Su questo non ci giurerei.
Questo è quello che ci vogliono far credere, ma alcune cosette mi fanno
pensare solo ad un p-code un pochino ottimizzato.
La prima che mi viene in mente è la neccessità del MSVB50VM.DLL (per il 5)
come motore.
Ma se l'exe è in codice macchina puro era proprio necessaria la libreria
esterna?
Poi, perchè VB continua ad avere un debug che permette di impostare il punto
d'esecuzione?
Delphi non lo permette (come giustamente dovrebbe essere su un'eseguibile)
[Roberto Negro]
Delphi senza meno. Ho scritto proprio oggi una routine che fa il CRC32
di un file da 256K in 25 centesimi di secondo (su un P166). Lo stesso
codice in VB e' 40 volte piu lento.
Beh, VB è famoso per la sua "lentezza", specie se lo utilizzi per leggere da
disco.
Però nel tuo caso penso che il collo di bottiglia sia nei cicli di
computazione del CRC, perchè se non fosse così, probabilmente la tua routine
si può ottimizzare.
Alla prossima.
Sono contento

probabilita' su  4 miliardi che non sia cosi').
Sei sicuro? Com'è questo fantastico CRC? Mi dici almeno su quale sistema si
basa?

Prova e poi mi saprai dire...
E' su it.binari.visual-basic sia il progetto VB sia VC++. Credo che
avrai qualche sorpresa... :-)
Ciao
Gian Michele Bertoni


della dimensione dell'eseguibile nella manutenzione del codice.
No, dicevo proprio codice sorgente: meno istruzioni, meno routine
portano a un codice piu' semplice da leggere, correggere, verificare,
manutenere...
;-)

basa?
Allego il sorgente per calcolare il crc di un array di 14 bytes.
CRC sta per Cyclic Redundancy Check, 32 per 32bit.
Viene utilizzato per identificare se un dato gruppo di bytes e' uguale
a un altro gruppo non accessibile, ma di cui e' noto il CRC.
Ad esempio nelle trasmissioni via modem:
- Trasmetto un blocco di 2048 bytes + 4 bytes di CRC.
- Il ricevente calcola il CRC dei 2048 bytes che sono arrivati a lui e
se e' diverso dal CRC che lui ha ricevuto capisce che c'e' stato
qualche errore nella trasmissione.
Si usa anche in programmi "illustri" tipo WINZIP...
C'e' un vecchio thread sull'argomento:
"Cyclical Redundancy Check (CRC) come ottenerlo in VB?"
-------------------------------------------------------------------------
Private Sub Form_Click()
Dim crc&(255), i&, crcv&, value&
i = 0
crc(i) = &H0: i = i + 1: crc(i) = &H77073096: i = i + 1: crc(i) =
&HEE0E612C: i = i + 1: crc(i) = &H990951BA: i = i + 1: crc(i) =
&H76DC419: i = i + 1: crc(i) = &H706AF48F: i = i + 1:
crc(i) = &HE963A535: i = i + 1: crc(i) = &H9E6495A3: i = i + 1: crc(i)
= &HEDB8832: i = i + 1: crc(i) = &H79DCB8A4: i = i + 1: crc(i) =
&HE0D5E91E: i = i + 1: crc(i) = &H97D2D988: i = i + 1:
crc(i) = &H9B64C2B: i = i + 1: crc(i) = &H7EB17CBD: i = i + 1: crc(i)
= &HE7B82D07: i = i + 1: crc(i) = &H90BF1D91: i = i + 1: crc(i) =
&H1DB71064: i = i + 1: crc(i) = &H6AB020F2: i = i + 1:
crc(i) = &HF3B97148: i = i + 1: crc(i) = &H84BE41DE: i = i + 1: crc(i)
= &H1ADAD47D: i = i + 1: crc(i) = &H6DDDE4EB: i = i + 1: crc(i) =
&HF4D4B551: i = i + 1: crc(i) = &H83D385C7: i = i + 1:
crc(i) = &H136C9856: i = i + 1: crc(i) = &H646BA8C0: i = i + 1: crc(i)
= &HFD62F97A: i = i + 1: crc(i) = &H8A65C9EC: i = i + 1: crc(i) =
&H14015C4F: i = i + 1: crc(i) = &H63066CD9: i = i + 1:
crc(i) = &HFA0F3D63: i = i + 1: crc(i) = &H8D080DF5: i = i + 1: crc(i)
= &H3B6E20C8: i = i + 1: crc(i) = &H4C69105E: i = i + 1: crc(i) =
&HD56041E4: i = i + 1: crc(i) = &HA2677172: i = i + 1:
crc(i) = &H3C03E4D1: i = i + 1: crc(i) = &H4B04D447: i = i + 1: crc(i)
= &HD20D85FD: i = i + 1: crc(i) = &HA50AB56B: i = i + 1: crc(i) =
&H35B5A8FA: i = i + 1: crc(i) = &H42B2986C: i = i + 1:
crc(i) = &HDBBBC9D6: i = i + 1: crc(i) = &HACBCF940: i = i + 1: crc(i)
= &H32D86CE3: i = i + 1: crc(i) = &H45DF5C75: i = i + 1: crc(i) =
&HDCD60DCF: i = i + 1: crc(i) = &HABD13D59: i = i + 1:
crc(i) = &H26D930AC: i = i + 1: crc(i) = &H51DE003A: i = i + 1: crc(i)
= &HC8D75180: i = i + 1: crc(i) = &HBFD06116: i = i + 1: crc(i) =
&H21B4F4B5: i = i + 1: crc(i) = &H56B3C423: i = i + 1:
crc(i) = &HCFBA9599: i = i + 1: crc(i) = &HB8BDA50F: i = i + 1: crc(i)
= &H2802B89E: i = i + 1: crc(i) = &H5F058808: i = i + 1: crc(i) =
&HC60CD9B2: i = i + 1: crc(i) = &HB10BE924: i = i + 1:
crc(i) = &H2F6F7C87: i = i + 1: crc(i) = &H58684C11: i = i + 1: crc(i)
= &HC1611DAB: i = i + 1: crc(i) = &HB6662D3D: i = i + 1: crc(i) =
&H76DC4190: i = i + 1: crc(i) = &H1DB7106: i = i + 1:
crc(i) = &H98D220BC: i = i + 1: crc(i) = &HEFD5102A: i = i + 1: crc(i)
= &H71B18589: i = i + 1: crc(i) = &H6B6B51F: i = i + 1: crc(i) =
&H9FBFE4A5: i = i + 1: crc(i) = &HE8B8D433: i = i + 1:
crc(i) = &H7807C9A2: i = i + 1: crc(i) = &HF00F934: i = i + 1: crc(i)
= &H9609A88E: i = i + 1: crc(i) = &HE10E9818: i = i + 1: crc(i) =
&H7F6A0DBB: i = i + 1: crc(i) = &H86D3D2D: i = i + 1:
crc(i) = &H91646C97: i = i + 1: crc(i) = &HE6635C01: i = i + 1: crc(i)
= &H6B6B51F4: i = i + 1: crc(i) = &H1C6C6162: i = i + 1: crc(i) =
&H856530D8: i = i + 1: crc(i) = &HF262004E: i = i + 1:
crc(i) = &H6C0695ED: i = i + 1: crc(i) = &H1B01A57B: i = i + 1: crc(i)
= &H8208F4C1: i = i + 1: crc(i) = &HF50FC457: i = i + 1: crc(i) =
&H65B0D9C6: i = i + 1: crc(i) = &H12B7E950: i = i + 1:
crc(i) = &H8BBEB8EA: i = i + 1: crc(i) = &HFCB9887C: i = i + 1: crc(i)
= &H62DD1DDF: i = i + 1: crc(i) = &H15DA2D49: i = i + 1: crc(i) =
&H8CD37CF3: i = i + 1: crc(i) = &HFBD44C65: i = i + 1:
crc(i) = &H4DB26158: i = i + 1: crc(i) = &H3AB551CE: i = i + 1: crc(i)
= &HA3BC0074: i = i + 1: crc(i) = &HD4BB30E2: i = i + 1: crc(i) =
&H4ADFA541: i = i + 1: crc(i) = &H3DD895D7: i = i + 1:
crc(i) = &HA4D1C46D: i = i + 1: crc(i) = &HD3D6F4FB: i = i + 1: crc(i)
= &H4369E96A: i = i + 1: crc(i) = &H346ED9FC: i = i + 1: crc(i) =
&HAD678846: i = i + 1: crc(i) = &HDA60B8D0: i = i + 1:
crc(i) = &H44042D73: i = i + 1: crc(i) = &H33031DE5: i = i + 1: crc(i)
= &HAA0A4C5F: i = i + 1: crc(i) = &HDD0D7CC9: i = i + 1: crc(i) =
&H5005713C: i = i + 1: crc(i) = &H270241AA: i = i + 1:
crc(i) = &HBE0B1010: i = i + 1: crc(i) = &HC90C2086: i = i + 1: crc(i)
= &H5768B525: i = i + 1: crc(i) = &H206F85B3: i = i + 1: crc(i) =
&HB966D409: i = i + 1: crc(i) = &HCE61E49F: i = i + 1:
crc(i) = &H5EDEF90E: i = i + 1: crc(i) = &H29D9C998: i = i + 1: crc(i)
= &HB0D09822: i = i + 1: crc(i) = &HC7D7A8B4: i = i + 1: crc(i) =
&H59B33D17: i = i + 1: crc(i) = &H2EB40D81: i = i + 1:
crc(i) = &HB7BD5C3B: i = i + 1: crc(i) = &HC0BA6CAD: i = i + 1: crc(i)
= &HEDB88320: i = i + 1: crc(i) = &H9ABFB3B6: i = i + 1: crc(i) =
&H3B6E20C: i = i + 1: crc(i) = &H74B1D29A: i = i + 1:
crc(i) = &HEAD54739: i = i + 1: crc(i) = &H9DD277AF: i = i + 1: crc(i)
= &H4DB2615: i = i + 1: crc(i) = &H73DC1683: i = i + 1: crc(i) =
&HE3630B12: i = i + 1: crc(i) = &H94643B84: i = i + 1:
crc(i) = &HD6D6A3E: i = i + 1: crc(i) = &H7A6A5AA8: i = i + 1: crc(i)
= &HE40ECF0B: i = i + 1: crc(i) = &H9309FF9D: i = i + 1: crc(i) =
&HA00AE27: i = i + 1: crc(i) = &H7D079EB1: i = i + 1:
crc(i) = &HF00F9344: i = i + 1: crc(i) = &H8708A3D2: i = i + 1: crc(i)
= &H1E01F268: i = i + 1: crc(i) = &H6906C2FE: i = i + 1: crc(i) =
&HF762575D: i = i + 1: crc(i) = &H806567CB: i = i + 1:
crc(i) = &H196C3671: i = i + 1: crc(i) = &H6E6B06E7: i = i + 1: crc(i)
= &HFED41B76: i = i + 1: crc(i) = &H89D32BE0: i = i + 1: crc(i) =
&H10DA7A5A: i = i + 1: crc(i) = &H67DD4ACC: i = i + 1:
crc(i) = &HF9B9DF6F: i = i + 1: crc(i) = &H8EBEEFF9: i = i + 1: crc(i)
= &H17B7BE43: i = i + 1: crc(i) = &H60B08ED5: i = i + 1: crc(i) =
&HD6D6A3E8: i = i + 1: crc(i) = &HA1D1937E: i = i + 1:
crc(i) = &H38D8C2C4: i = i + 1: crc(i) = &H4FDFF252: i = i + 1: crc(i)
= &HD1BB67F1: i = i + 1: crc(i) = &HA6BC5767: i = i + 1: crc(i) =
&H3FB506DD: i = i + 1: crc(i) = &H48B2364B: i = i + 1:
crc(i) = &HD80D2BDA: i = i + 1: crc(i) = &HAF0A1B4C: i = i + 1: crc(i)
= &H36034AF6: i = i + 1: crc(i) = &H41047A60: i = i + 1: crc(i) =
&HDF60EFC3: i = i + 1: crc(i) = &HA867DF55: i = i + 1:
crc(i) = &H316E8EEF: i = i + 1: crc(i) = &H4669BE79: i = i + 1: crc(i)
= &HCB61B38C: i = i + 1: crc(i) = &HBC66831A: i = i + 1: crc(i) =
&H256FD2A0: i = i + 1: crc(i) = &H5268E236: i = i + 1:
crc(i) = &HCC0C7795: i = i + 1: crc(i) = &HBB0B4703: i = i + 1: crc(i)
= &H220216B9: i = i + 1: crc(i) = &H5505262F: i = i + 1: crc(i) =
&HC5BA3BBE: i = i + 1: crc(i) = &HB2BD0B28: i = i + 1:
crc(i) = &H2BB45A92: i = i + 1: crc(i) = &H5CB36A04: i = i + 1: crc(i)
= &HC2D7FFA7: i = i + 1: crc(i) = &HB5D0CF31: i = i + 1: crc(i) =
&H2CD99E8B: i = i + 1: crc(i) = &H5BDEAE1D: i = i + 1:
crc(i) = &H9B64C2B0: i = i + 1: crc(i) = &HEC63F226: i = i + 1: crc(i)
= &H756AA39C: i = i + 1: crc(i) = &H26D930A: i = i + 1: crc(i) =
&H9C0906A9: i = i + 1: crc(i) = &HEB0E363F: i = i + 1:
crc(i) = &H72076785: i = i + 1: crc(i) = &H5005713: i = i + 1: crc(i)
= &H95BF4A82: i = i + 1: crc(i) = &HE2B87A14: i = i + 1: crc(i) =
&H7BB12BAE: i = i + 1: crc(i) = &HCB61B38: i = i + 1:
crc(i) = &H92D28E9B: i = i + 1: crc(i) = &HE5D5BE0D: i = i + 1: crc(i)
= &H7CDCEFB7: i = i + 1: crc(i) = &HBDBDF21: i = i + 1: crc(i) =
&H86D3D2D4: i = i + 1: crc(i) = &HF1D4E242: i = i + 1:
crc(i) = &H68DDB3F8: i = i + 1: crc(i) = &H1FDA836E: i = i + 1: crc(i)
= &H81BE16CD: i = i + 1: crc(i) = &HF6B9265B: i = i + 1: crc(i) =
&H6FB077E1: i = i + 1: crc(i) = &H18B74777: i = i + 1:
crc(i) = &H88085AE6: i = i + 1: crc(i) = &HFF0F6A70: i = i + 1: crc(i)
= &H66063BCA: i = i + 1: crc(i) = &H11010B5C: i = i + 1: crc(i) =
&H8F659EFF: i = i + 1: crc(i) = &HF862AE69: i = i + 1:
crc(i) = &H616BFFD3: i = i + 1: crc(i) = &H166CCF45: i = i + 1: crc(i)
= &HA00AE278: i = i + 1: crc(i) = &HD70DD2EE: i = i + 1: crc(i) =
&H4E048354: i = i + 1: crc(i) = &H3903B3C2: i = i + 1:
crc(i) = &HA7672661: i = i + 1: crc(i) = &HD06016F7: i = i + 1: crc(i)
= &H4969474D: i = i + 1: crc(i) = &H3E6E77DB: i = i + 1: crc(i) =
&HAED16A4A: i = i + 1: crc(i) = &HD9D65ADC: i = i + 1:
crc(i) = &H40DF0B66: i = i + 1: crc(i) = &H37D83BF0: i = i + 1: crc(i)
= &HA9BCAE53: i = i + 1: crc(i) = &HDEBB9EC5: i = i + 1: crc(i) =
&H47B2CF7F: i = i + 1: crc(i) = &H30B5FFE9: i = i + 1:
crc(i) = &HBDBDF21C: i = i + 1: crc(i) = &HCABAC28A: i = i + 1: crc(i)
= &H53B39330: i = i + 1: crc(i) = &H24B4A3A6: i = i + 1: crc(i) =
&HBAD03605: i = i + 1: crc(i) = &HCDD70693: i = i + 1:
crc(i) = &H54DE5729: i = i + 1: crc(i) = &H23D967BF: i = i + 1: crc(i)
= &HB3667A2E: i = i + 1: crc(i) = &HC4614AB8: i = i + 1: crc(i) =
&H5D681B02: i = i + 1: crc(i) = &H2A6F2B94: i = i + 1:
crc(i) = &HB40BBE37: i = i + 1: crc(i) = &HC30C8EA1: i = i + 1: crc(i)
= &H5A05DF1B: i = i + 1: crc(i) = &H2D02EF8D: i = i + 1
Dim a(1 To 14) As Byte
a(1) = &H50
a(2) = &H4B
a(3) = &H3
a(4) = &H4
a(5) = &H14
a(6) = &H0
a(7) = &H2
a(8) = &H0
a(9) = &H8
a(10) = &H0
a(11) = &HA0
a(12) = &HD
a(13) = &H98
a(14) = &H25
crcv = &HFFFFFFFF
For i = 1 To 14
 value = a(i)
 If crcv = 0 Then crcv = &HFFFFFFFF
 crcv = crc((crcv Xor value) And &HFF&) Xor (Int(crcv / 256) And
&HFFFFFF)
Next
crcv = crcv Xor &HFFFFFFFF
MsgBox ("CRC32: $" & Hex$(crcv))
End Sub
-------------------------------------------------------------------------


A sě?, mi devo essere sconfusionato... x-)
Ciao.

 wrote:
Beh, direi che ne è uscito proprio un bel thread :)
Mi sono chiarito le idee, tnx a tutti.
Alla fine ho ordinato Delphi 4 Standard (a proposito, non vi sembra
scandaloso che in tutta Piacenza non ci fosse un negozio di
informatica che ne avesse una copia in casa?) e ho installato anche
VB6 working model edition, così do' un'occhiata anche a VB (1- chi mi
spiega perchè ho dovuto installarmi anche IE 4 per farlo andare?
2- con questa versione non si possono creare .exe perchè è una sorta
di trial oppure sono io incapace?).
Per quanto riguarda Delphi devo dire che mi aspettavo un manuale
cartaceo un po' + corposo, e anche l'help in linea non mi sembra il
massimo (sono le primissime impressioni).
Intanto che ci sono mi consigliate qualche tutorial sul Web (se è in
ITA meglio)?
Grazie.


pari a quella del mio criceto...
In un mondo dove la madre degli idioti e' sempre gravida è ovvio che uno
"p-programmatore" scelga il prodotto pi semplice da usare.
Il fatto è che (PER FORTUNA DEI PROFESSIONISTI, -mi ci metto anch'io?-) per
quanto il prodotto sia semplice, la qualita' del risultato e' inversamente
proporzionale all'incapacità del programmatore.

d'esecuzione?
Stai confondendo due cose completamente distinte.
Una cosa e' l'ambiente di sviluppo VB (dove l'esecuzione e' INTERPRETAZIONE
del codice, non compilazione),
un'altra e' il programma compilato (in nativo o P-CODE che sia).
--
Roal Zanazzi
z...@iol.it

 
Cosa intendi dire con quel "chi volete che vinca?"
Cosa significa vincere?
Inprise ha cambiato molto nella sua politica, Delphi non e' come il vecchio
pascal che si insegnava nelle scuole.
Prima di tutto le librerie di Borland hanno ridotto il casino dell'utilizzo
di Windows senza rinunciare alla potenza. La struttura della libreria a
classi mi sembra ben fatta e la struttura determina la base di ogni
programma. Windows nascendo come sistema scritto in c (e non c++) si e
portato tutte le problematiche di una struttura incasinata (non fluida).
Inprise ha molta esperienza di "struttura" di libreria partendo dal vecchio
Turbo Vision per DOS nato con la versione 6.0 del Turbo Pascal e riportato
nella Borland C++. 
Inprise inoltre si e' buttata su tutto cio' che sta intorno al linguaggio
(Midas, Visibroker, ...) e dunque possiede una serie di pacchetti
(tecnologie) che non sono facilmente rimpiazzabili da Microsoft. Ad esempio
Inprise ha JBuilder che crea codice 100% Java, Microsoft no, Inprise
supporta DCOM e CORBA ed ha C++ Builder che e' un C++ RAD. Delphi di per sè
tecnologicamente e' sempre stato avanti di un ANNO rispetto a C++ Builder.
Dunque Borland passando a Inprise ha cambiato la sua offerta da linguaggi e
database (paradox,dbase) a linguaggi e tecnologia...
Per quanto riguarda lo scontro VB-Delphi bisognerebbe fare un'indagine
sulle applicazioni effettuate con i due linguaggi e vedere cosa ne e'
venuto fuori, quanto tempo ci si mette a modificare il programma e in
quanto tempo e' stato effettuato il tutto.
Matteo Tosato as qexxis

di trial oppure sono io incapace?).
Immagino la prima che hai detto.
--
Roal Zanazzi
z...@iol.it

un'altra e' il programma compilato (in nativo o P-CODE che sia).
No, intendevo il fatto che in debug io posso decidere dove posizionare il
punto d'esecuzione (non il break point).
Se fosse possibile una cosa del genere su un vero codice macchina perchè
Delphi non lo permette?
Ciao.
Ormai ho rinunciato a farti ricredere sulle capacità di Delphi, tra l'altro
non era mia intenzione farlo, ma su alcuni punti non mi trovo proprio
d'accordo (se fossimo tutti d'accordo su tutto come faremmo a far ingrossare
thread come questo? Il mondo è bello perchè vario, diceva un proverbio)

 massimo (sono le primissime impressioni).
Il problema del manuale e' sicuramente una cosa seria, in Delphi 1 i
manuali erano consistenti, Poi sono calati sempre di più, nella versione 4
sono striminziti. Ritengo che i manuali siano importanti perche' si possono
leggere in qualunque posto e poi danno l'idea che il software e' originale
e non copiato!! L'help va benissimo quando si scrive il codice ma quando si
impara occorre qualcosa di staccato.
Il problema si fa maggiormente rilevante perche' non esistino a parer mio
in libreria dei libri su Delphi che possono sostituire i manuali, in genere
sono dei libroni dove si parla di tutto ma sostanzialmente superficiali.
E poi per chi vuole imparare a programmare a oggetti, dove impara? nON HO
TROVATO UN LIBRO CHE SPIEGHI GLI OGGETTI partendo dal linguaggio Delphi,
cosa deve fare uno, comprare un classico del c++, imparare su quel libro e
trasferire le conoscenze in Delphi?
Io ho imparato la programmazione a oggetti con la libreria Turbo Vision del
Pascal 6, vi era una parte che spiegava proprio la programmazione, poi sono
passato al c++ e ho imparato sui libri classici e poi continuando a
lavorare in pascal sapevo le differenze tra i due linguaggi lette sul
manuale del linguaggio del pascal.
Ma ora chi acquista Delphi come fa a imparare?  I libri in genere parlano
delle caratteristiche della programmazione OOP ma non ci sono esempi
progressivi, la cosa e' troppo striminzita.
Dunque dai libri standard si impara a usare l'IDE e la VCL, a fare
applicazioni guidate, ma non si impara a programmare a oggetti.
Matteo Tosato as Qexxis         

quanto tempo e' stato effettuato il tutto.
Un confronto simile e' piuttosto difficile, per il semplice motivo che
nessuna software house con un po' di cervello vorrebbe fare lo stesso
applicativo in Delphi E in VB, giusto per fare un confronto tra i due
ambienti...
--
Roal Zanazzi
z...@iol.it

soprattutto i sorgenti della libreria.
Non me lo posso permettere...sono uno studente... :)



OK, l'ho scaricato, ho compilato il progetto VB, sia in P-CODE che in nativo
con VB5.
Poi ho fatto lo stesso progetto in Delphi, l'algoritmo e' identico (tanto
che ho fatto copia-incolla dal tuo sorgente e poi ho modificato la
sintassi).
Mi dispiace solo non aver provato quello per Visual C++, ma VC e' duranto
solo una settimana sul mio hard-disk (dopo di che' ha fatto un bel volo giu'
dalla finestra!)
Dato che tu hai parlato (scritto) di "prestazioni globali decenti", ho
deciso di prendere in considerazione non solo il tempo di calcolo dei numeri
primi, ma anche quello di visualizzazione degli stessi nella listbox (quando
possibile, dato che la listbox non puo' contenere tantissime righe).
Condizioni del test:
1) VB5 + SP3 compilato in P-CODE
    EXE = 9KB + 1.3MB DLL Runtime + DLL OLE...
2) VB5 + SP3 compilato in nativo con ottimizzazioni per velocita'
    EXE = 12KB + 1.3MB DLL Runtime + DLL OLE...
3) Delphi 3.01 compilato con ottimizzazioni
    EXE = 199KB (e niente DLL!)
    oppure, volendo, EXE = 12KB + 1.2MB VCL30.DPL (package)
Ecco i risultati comparativi (i dati si riferiscono al mio scarso PC),
i dati numerici sono in millisecondi e si riferiscono al tempo di calcolo ed
al tempo totale (compresa la visualizzazione) e sono tempi medi su piu'
prove:
numeri       VB P-CODE    VB nativo      Delphi
1000          0 - 96                0 - 85             0 - 45
10000        69 - 750           13 - 660         9 - 370
100000      890 - 6200      138 - 5200     120 - 3000
1000000    11193 - n.a.     2080 - n.a.     1855 - n.a.
10000000  156877 - n.a.  26863 - n.a.    25187 - n.a.
NOTA: nell'ultimo passaggio (10000000) ho controllato (per curiosità) la
situazione della memoria allocata con il Monitor di sistema di Windows95B:
da un controllo superficiale sembra che entrambi gli EXE VB abbiano allocato
molta piu' memoria dell'EXE di Delphi; questo e' piuttosto indicativo sulle
performance di utilizzo delle risorse da parte dei due linguaggi.
Come si vede dai risultati (i test sono stati effetuati con le medesime
condizioni), effettivamente VB5 compilato in nativo offre prestazioni simili
a quelle di Delphi, almeno per quanto riguarda il calcolo puro (anche se
Delphi e' comunque piu' performante).
Per quanto riguarda invece il test piu' indicativo per la verifica delle
prestazioni globali di una normale applicazione (ossia le performance
dell'interfaccia utente), direi che non c'e' proprio paragone, Delphi vince
alla stragrande. Da notare che, mentre nel codice VB vengono usare le API
(SendMessage) per disabilitare il refresh della listbox durante
l'inserimento delle righe, in Delphi questo non e' necessario, quindi, pur
usando un "trucco" VB e' quasi 2 volte piu' lento di Delphi.
So benissimo che questo piccolo test non e' estensivo, non prende in
considerazioni molti aspetti (ad esempio l'accesso al disco), ma mi sembra
comunque indicativo.
Per correttezza, ho spedito a Gian Michele Bertoni tutti i sorgenti e gli
eseguibili che ho utilizzato per il test, cosi' puo' verificare di persona i
risultati (ovviamente i dati numerici saranno differenti, perche' dipendono
dal PC, ma i rapporti tra essi saranno simili).
--
Roal Zanazzi
z...@iol.it


z...@iol.it

thread come questo? Il mondo è bello perchè vario, diceva un proverbio)
Il mondo e' bello perche' e' avariato ;-)
--
Roal Zanazzi
z...@iol.it

 TROVATO UN LIBRO CHE SPIEGHI GLI OGGETTI partendo dal linguaggio Delphi,
Su "Delphi 2" di Marco Cantu' ci sono un paio di capitoli buoni per
questo
uno sulla parte procedurale del linguaggio ed uno sulla programmazione
ad
oggetti, il primo e' un po' lacunoso e da molte cose per scontate, il
secondo
invece e' molto ben fatto, sintetico e chiaro con esempi calzanti,
secondo me
quel capitolo vale tutto il libro.
Ciao...
Claudio Driussi

 Non me lo posso permettere...sono uno studente... :)
Allora sara' per la prossima versione :-)
Ciao...
Claudio Driussi

 di un metodo di un oggetto (allorchè D non sa più che pesci pigliare)
per evitare i conflitti di nome, basta che fai precedere il nome della
unit
al nome della funzione, ad esempio:
with Table1 do begin
  if Eof then            // eof di Table1
    if System.Eof then   // funzione Eof della unit System
      ...
end;
Ciao...
Claudio Driussi

Microsoft non perdono occasione per forzarti ad installare IE4!
L'help in linea non esiste in questa versione, ci sono solo 2 miseri
file HTML (solo testo, li vedresti benissimo anche con Lynx...)
riguardanti l'installazione di VB....e per questi due files mi
costringono a installare IE4 (obbligatoria l'ultimissima versione tra
l'altro, xchè con la penultima non andava) e OLE? 
Secondo me è scandaloso...spero che IE4 sia utile a VB6 anche x
qualcos'altro...



Dunque, sul Sito Comune di VB dovrebbe andare solo materiale VB, quindi non
so se sia il caso di metterci sorgenti Delphi (anche se, magari, nello
stesso zip con quelli VB non e' un problema). Ettore Maronese, che ne dici?
Per quanto riguarda il repository di Mr.Coke, da qualche settimana non
riesco piu' a collegarmi, mi dice che non trova il server :-(   Se mando a
te (Eugenio) lo zip, potresti cortesemente postarlo tu? E se mi mandi anche
per e-mail l'IP del repository... magari e' cambiato?
Ciao
--
Roal Zanazzi
z...@iol.it

non puoi fare le stesse operazioni che fai da DENTRO l'ambiente VB.
Allora perchè VB5 e succ. consentono l'utilizzo di api enumerative e di
callback, che gli esperti definivano impossibili da implementare in un
linguaggio interpretato?
Se nell'IDE vb interpreta, non dovrebbe funzionare...
Ciao

...
GMB>Non ho provato, ma se fai un crivello di Eratostene in GMB>VC++ ed
in VB le prestazioni dovrebbero essere simili.
RZ>Ah, ah, ah... ottimista sognatore! :-)
RZ>Prova e poi mi saprai dire...
GMB>E' su it.binari.visual-basic sia il progetto VB sia GMB>VC++. Credo
che avrai qualche sorpresa... :-)
RZ>OK, l'ho scaricato, ho compilato il progetto VB, sia in RZ>P-CODE che
in nativo con VB5.
RZ>Poi ho fatto lo stesso progetto in Delphi, l'algoritmo RZ>e' identico
(tanto che ho fatto copia-incolla dal tuo RZ>sorgente e poi ho
modificato la sintassi).
...segue test...
RZ>Come si vede dai risultati (i test sono stati effetuati RZ>con le
medesime condizioni), effettivamente VB5 RZ>compilato in nativo offre
prestazioni simili a quelle RZ>di Delphi, almeno per quanto riguarda il
calcolo puro RZ>(anche se Delphi e' comunque piu' performante).
Ok, quindi da ottimista sognatore sono diventato lucido realista...:-) I
risultati sono simili, quindi lasciamo da parte il calcolo e passiamo
alla prossima questione.
Purtroppo, a questo punto, -pop- ti spuntano le ventose ai piedi ed
inizi un'evoluzione acrobatica su pareti levigate.... :- Infatti...
GMB>quello che volevo dire e' che i "seri problemi di
GMB>performance" non sono poi cosi' seri nel contesto di GMB>una normale
applicazione che fa un po' di calcolo,
GMB>accede al disco, ecc
RZ>Dato che tu hai parlato (scritto) di "prestazioni
RZ>globali decenti", ho deciso di prendere in RZ>considerazione non solo
il tempo di calcolo dei
RZ>numeri primi, ma anche quello di visualizzazione degli RZ>stessi
nella listbox (quando possibile, dato che la RZ>listbox non puo'
contenere tantissime righe).
...dati del test...
RZ>Per quanto riguarda invece il test piu' indicativo per RZ>la verifica
delle prestazioni globali di una normale RZ>applicazione (ossia le
performance dell'interfaccia RZ>utente), direi che non c'e' proprio
paragone, Delphi
RZ>vince alla stragrande.
Mi sembra una grossa forzatura quella di identificare (o anche solo di
usare ad esempio) le prestazioni dell'UI con le prestazioni globali.
Infatti e' noto che la maggior parte del tempo di elaborazione di un'UI
e' speso nell'attendere le azioni dell'utente. Quando anche questa non
fosse una forzatura, lo e', pero', l'identificare le prestazioni di un
listbox con quelle di tutta un'UI. Mi rendo conto che fare prove
esaustive sui componenti di un'interfaccia e' dispendioso, ma mostrare
le prestazioni comparate di un listbox per dimostrare la tesi in
questione e' quantomeno pretenzioso!
Il "colpo di grazia" sulle tue tesi, infine, arriva dai dati: essi sono
validi solo su Win95/98, ma su NT le differenze scendono al 15-16% per
la prima prova, al 9% per la seconda ed al 7% per la terza. Su NT
oltretutto, scompaiono i limiti del listbox e la risoluzione di
GetTickCount e' 10 ms circa, rendendo la prova piu' significativa (fatte
salve le considerazioni espresse prima).
I miei dati su NT4 SP3 sono i seguenti:
   numeri      VB nativo         Delphi
  100.000           1915           1665
1.000.000          21009          19270
4.000.000         120445         112663
Le prove sono state condotte lanciando 13 volte il calcolo e facendo la
media sugli ultimi 10 risultati (scartando i primi 3) ed usando gli
eseguibili spediti in email da Roal. Da notare che sull'ultima prova
l'applicativo Delphi ha dato per due volte l'errore "Unable to insert
item" il che mi fa pensare che il garbage collector sara' si' piu'
efficiente, ma si lascia anche un bel po' di lavoro arretrato! :-)
Comunque la tesi che non ci sono poi differenze drammatiche, mi sembra
dimostrata.
E adesso una piccola nota di colore...
RZ>Mi dispiace solo non aver provato quello per Visual RZ>C++, ma VC e'
duranto solo una settimana sul mio hard-RZ>disk (dopo di che' ha fatto
un bel volo giu' dalla RZ>finestra!)
E male hai fatto! Guarda un po' come gira il test con VC++:
   numeri           VC++         Delphi
  100.000            334           1665
1.000.000           8847          19270
4.000.000          76420         112663
I dati sono relativi sempre a NT4 SP3, ma dalle 3 prove che ho fatto su
Win98 la situazione per Delphi e' anche peggiore: 1250 ms contro 6500 ms
su 300.000 numeri.
Ciao
Gian Michele Bertoni
P.S. Per la cronaca, il computer NT4 e' un P200 Pro con 128 MB RAM
mentre il Win98 e' un P200 MMX con 64 MB RAM.


...
GMB>Non ho provato, ma se fai un crivello di Eratostene in
GMB>VC++ ed in VB le prestazioni dovrebbero essere simili.
RZ>Ah, ah, ah... ottimista sognatore! :-)
RZ>Prova e poi mi saprai dire...
GMB>E' su it.binari.visual-basic sia il progetto VB sia
GMB>VC++. Credo che avrai qualche sorpresa... :-)
RZ>OK, l'ho scaricato, ho compilato il progetto VB, sia in
RZ>P-CODE che in nativo con VB5.
RZ>Poi ho fatto lo stesso progetto in Delphi, l'algoritmo
RZ>e' identico (tanto che ho fatto copia-incolla dal tuo
RZ>sorgente e poi ho modificato la sintassi).
...segue test...
RZ>Come si vede dai risultati (i test sono stati effetuati
RZ>con le medesime condizioni), effettivamente VB5
RZ>compilato in nativo offre prestazioni simili a quelle
RZ>di Delphi, almeno per quanto riguarda il calcolo puro
RZ>(anche se Delphi e' comunque piu' performante).
Ok, quindi da ottimista sognatore sono diventato lucido realista...:-) I
risultati sono simili, quindi lasciamo da parte il calcolo e passiamo
alla prossima questione.
Purtroppo, a questo punto, -pop- ti spuntano le ventose ai piedi ed
inizi un'evoluzione acrobatica su pareti levigate.... :-) Infatti...


4.000.000          76420         112663
La differenza mi pare esagierata.
Non so che test avete fatto, ma penso che avete compilato VC++ e Delphi in
modo differente, chesso', il primo usando il cooprocessore matematico ed il
secondo no, o roba simile.
Ciao
By -MES-   Maronese Ettore
http://ilmes.freeweb.org
(con OCX per stampare i recordset)
Sito Comune di programmatori Visual Basic
http://members.xoom.com/it_lang_vb


<snip>
Le migliori prestazioni dell'EXE VC++, per quanto riguarda il riempimento
della listbox sono dovute al fatto che nel programma Delphi non ho usato il
SendMessage con WM_SETREDRAW (il "trucchetto" a cui mi riferivo prima).
Mettendo quelle due righe nel codice Delphi le prestazioni sono decisamente
migliorate (ancora superiori, ma scendono da 3000ms a circa 980ms per
100000 numeri, contro i 740ms di VC++... e scommetto che buona parte del gap
e' causato dalla funzione di conversione numero->stringa ;-).
Come vedi, dipende dal codice (e stiamo confrontando pascal con C)...
Aspetto che mi rimandi i src VC++, per farne un'analisi (magari
semplicemente per mia personale curiosita').
Comunque ti invito a leggere il subject di questo thread ed a trarne le
relative conclusioni sull'introduzione dell'argomento VC++  >:-)
--
Roal Zanazzi
z...@iol.it

 nemmeno io riesco piu' a collegarmi,
   Rettifico,
   ora, sono le 12.10
   il server :  194.243.237.10
   e' di nuovo attivo
Eugenio
-

Se nell'IDE vb interpreta, non dovrebbe funzionare...
Come nota: le callback nell'IDE ogni tanto fanno casino (non sempre, ma
capita).
--
Roal Zanazzi
z...@iol.it

listbox. (tra l'altro in VB l'hai dovuta "truccare" con le API ;-)
Grazie, ti voglio bene! Tuttavia questa cosa del "trucco" va un po'
spiegata: ho spedito su it.binari.visual-basic una versione del crivello
in VB e VC++ perche', dalle prove che avevo fatto, le prestazioni di
calcolo erano simili ed immaginavo che anche per Delphi fosse lo stesso,
come poi mi hai confermato.
Per me il discorso finiva li' ed ho usato la SendMessage non perche' la
consideri un trucco, ma, al contrario,  una buona norma nel caso si
debba riempire con tanti elementi un listbox.
Solo dopo tu mi hai spedito i tuoi sorgenti e compilati tirando fuori,
dopo che i dati sul calcolo mi davano ragione, la questione del listbox
sulla quale ho espresso le mie perplessita', ma sulla quale, per amor di
discussione, ho voluto produrre altri dati.
Non e' una forzatura produrre dati riguardanti NT perche' essi non vanno
a suffragio di nessuna tesi, avendo gia scritto che ritenevo pretestuoso
il test sul listbox.
Riguardo al presunto "Garbage Collector" di Delphi, ritengo che, se c'e'
un framework, e' presumibile che durante l'idle time qualche operazione
di pulizia venga fatta. Ma posso sbagliarmi, naturalmente.
Comunque non voglio polemizzare ne' finire OT. Anzi da parte mia non
puo' che esserci stima per chi, come te, contribuisce in maniera attiva
alla vita di questo NG.
Un saluto
Gian Michele Bertoni


secondo no, o roba simile.
Niente trucchi, niente inganni, siore! Trattasi di genuino programma MFC
compilato "Release" con opzioni di default e senza nessuna
programmazione "esoterica" tipo matematica dei puntatori. E poi c'e'
ancora l'opzione del coprocessore su Delphi ? Oggi tutti i Pentium hanno
il coprocessore...
Scherzi a parte, la differenza sta probabilmente in quel messaggio
WM_SETREDRAW che invio prima di aggiornare il listbox, ma sul quale ho
espresso le miei considerazioni in un altro messaggio in questo thread.
Ciao


Impossibili? E perche' mai?
Ben detto. Mi preme infatti sottolineare un aspetto importante per il
debugging: non solo e' possibile usare l'IDE con callback e thread
diversi da quello principale, ma si possono inserire i breakpoints
all'interno delle stesse routine. Non posso dirlo con certezza, ma mi
sembra che il GPF (o chi per lui) sia in agguato se, e solo se, c'e'
accesso contemporaneo a zone di memoria condivise (anche in senso
estensivo: ovvero se si entra in una macchina a stati "sensibile" o "non
rientrante" prima che questa finisca il suo compito).
In questi casi diventa importante l'uso degli oggetti di
sincronizzazione forniti dal kernel come sezioni critiche, eventi,
mutex, ecc.
In VB rimane comunque la possibilita' di compilare disabilitando le
ottimizzazioni ed abilitando la generazione delle informazioni
simboliche di debug. A questo punto e' possibile usare il debugger del
Visual Studio (che non supporta pienamente i sorgenti VB, ma quel che fa
basta e avanza) o equivalente.


funziona, quindi probabilmente gli esperti si sono sbagliati ;-)
Beh, probabile, mi ero dimenticato dell'assioma
se un'esperto dice che non si può fare è perchè lui non ne è capace.
Ciao

espresso le miei considerazioni in un altro messaggio in questo thread.
Infatti... ho aggiunto quelle 2 righe nel programma Delphi e le prestazioni
sono notevolmente migliorate, anche se sono ancora peggiori di quelle di
VC++.
Ovviamente una spiegazione c'e', e a mio parere e' semplice:
il sorgente VC++ e' praticamente C-style (perche' il framework MFC ha un
overhead minimo, essendo un wrapper verso le API poco articolato).
In Delphi (ed in C++Builder), invece, ho utilizzato normalmente il framework
di classi VCL, che, ovviamente, hanno un overhead aggiuntivo (e' il giusto
prezzo per una semplicita' di sviluppo notevolmente maggiore).
Si potrebbe riscrivere in Delphi (o C++Builder) lo stesso programma in
C-Style (gestione dei messaggi, etc...)
ma, sinceramente, non ne ho alcuna voglia ne' il tempo...
tanto e' inutile farsi le seghe mentali... lavoro in VB, che volete che mi
interessi se Delphi e' piu' o meno performante di VC++?
In entrambi i casi, VB e' comunque peggio >:-)
--
Roal Zanazzi
z...@iol.it

In entrambi i casi, VB e' comunque peggio >:-)
Parole sante. La cosa interessante e' che l'accoppiata dei due (cosa
certamente prevista e voluta dal marketing Microsoft) porta a risultati
notevoli mantenendo (piu' o meno) il meglio dei due mondi.
Ciao
Gian Michele Bertoni
P.S. Hai letto degli Halloween documents ?


 potra' farlo.
Ho postato alcune mie considerazioni sui sorgenti dei test e sui benchmark
in genere.
Quanto al thread VB-Delphi in un programma reale la differenza si fa sentire
pesantemente anche se e' compilato, a causa dell'inefficenza generale delle
chiamate in memoria e dalla gestione delle finestre.
Ciao Uberto
.