Newsgroup: it.comp.lang.visual-basic
Titolo: domanda .NET

Non ho capito bene una cosa. Ho letto un articolo in cui si spiegava che la 
compilazione nel framework .NET è gestita da un motore centralizzato che si 
occupa di ottimizzare il codice indipendentemente dall'ambiente di sviluppo 
utilizzato. Mi sono spiegato malissimo. Cmq sembrerebbe che lavorare in VB o 
VC non cambi poi molto in termini di esecuzione del software e quindi non ci 
siano più linguaggi di serie A o B. E' giusto? quindi se uso 
VB.NET
 dovrei 
raggiungere le stesse prestazioni di VC in termini di velocità???? 

 raggiungere le stesse prestazioni di VC in termini di velocità???? 
ALT! Momento: prima che venga detta qualche eresia(in buona o mala fede
importa poco), precisiamo un dettaglio, cioè che VC++ può essere
compilato in managed o unmanaged code. Il default è unmanaged.
Per motivi ovvi che spero siano molto ovvi(scusate il bisticcio di
parole), la compilazione nativa Win32 è più performante di quella
dotNET. Sono sicuro che troverai qualcuno che ti dice che non è
vero, che dotnet ha la stessa velocità di Win32, ecc... non gli
credere, perché dice una cosa inesatta.
Comunque, tornando a noi: C# e VC++ possono usare i puntatori
anche in dotNET(usando delle keyword possono ottenere l'accesso
alla memoria, a quello che ricordo), quindi saranno ovviamente più
performanti di 
VB.NET
 che i puntatori non sà manco che sono
(giustamente, aggiungerei).
Ciao,
Andrea

 (giustamente, aggiungerei).
ALT: fermiamoci ancora un attimo :)
Tralascio il VC++ che è un caso particolare.
Parliamo di linguaggi managed "normali" come c#, delphi# (o come si chiama)
e 
vb.net
.
La loro velocità a *parità* di istruzioni usate sono del tutto assimilabili.
Ovvio che se uno permette l'uso dei puntatori e 
vb.net
 lo si usa con ancora
le vecchie funzioni di compatibilità come Mid() le differenze iniziano a
farsi sentire.
Ciao
--
Reporting tool: 
http://www.neodatatype.net
Qualunque mentecatto può scrivere codice che un computer possa capire.
I buoni programmatori scrivono codice che gli uomini possano capire.
[Martin Fowler]

 Ciao
Ciao,
Andrea

 (giustamente, aggiungerei).
ma supponiamo che crei un programma (ad esempio una simulazione numerica) in 
VC++.NET che non usa i puntatori e poi lo "traduca" pari passo in 
VB.NET
,
quale dei due sarà più performante? 

 venga usata da MS... a buon intenditor...).
IMHO la dice anche molto lunga sulla schizofrenia del marketing
microsoft. Un linguaggio "sicuro" come dovrebbe essere .net non
dovrebbe avere puntatori, che  hanno senso in linguaggi di piu`
basso livello.
-- 
ciao, hal

 basso livello.
beh dipende a volte l'uso dei puntatori puň essere importante in certi 
ambiti di programmazione anche se ormai
si sta cercando di non utilizzarli piů. Se non ci fossero e mi servissero? a 
parte tutto .net non mi sembra un linguaggio
piuttosto una piattaforma. O sbaglio? 

 piuttosto una piattaforma.
Concordo. E una piattaforma dovrebbe astrarre dal sistema
reale sottostante, altrimenti  non capisco perche` dovrei
usarla. Quindi: niente puntatori ;-)
-- 
ciao, hal

 usarla. Quindi: niente puntatori ;-)
sě perň non penso si possa eliminare dal VC++ i puntatori! 


Ci mancherebbe :-)
Tant'e` che si sono inventati codice managed ed unmanaged.
-- 
ciao, hal

 Tant'e` che si sono inventati codice managed ed unmanaged.
che cosa sarebbe? 

 quale dei due sarà più performante? 
Non penso che tu possa tradurlo efficacemente.
Andrea

> Non penso che tu possa tradurlo efficacemente.
perché no? se prendo ad esempio un algoritmo "generico" e lo traduco prima 
in C e poi in vb qual è il problema? ad esempio
prendi un algoritmo numerico per il calcolo degli integrali. Non vedo quale 
sia la difficoltà a convertirlo in vb. Se riesci a spiegarmelo. 


Non so come sia con 
vb.net
, ma con vc++ se usi le managed extensions
puoi scrivere classi managed ( cioe` create nel managed heap) oppure
classi tradizionali.
Per distinguerle e` stata introdotta la direttiva __gc:
// creata nel managed heap
// deriva implicitamente da System::Object
__gc class Qualcosa
{
	// ...
}
// creata nell'heap non gestito dal CLR
// *non* deriva da alcuna classe del framework
class Qualcosaltro
{
	// ...
}
Anche l'istanziazione (che brutta parola: ma si dice davvero cosi`?)
di un oggetto managed avviene con una propria new:
Qualcosa* qualcosa = new Qualcosa; // __gc new "implicito"
-- 
ciao, hal

 Comunque, per amor di precisione, si chiama Delphi.Net .
L'ho incluso nella lista solo perchè so che esiste, potrei citare anche il
fortran.net
 o il 
cobol.net
, ma non ho intenzione di cercarmi tutti i
linguaggi .net che si stanno inventando.
Mi pare ci sia pure un Ada.Net, ma quanti sanno che esisteva un Ada
"liscio"?


 ha scritto nel messaggio
news:yij%d.1089157$35.40...@news4.tin.it...

Vb.Net non ha un pieno supporto ai puntatori.
Se parti da codice managed il risultato sarà per forza di cose diverso
dall'originale come implementazione.
Potresti anche non riuscire a tradurre il codice.


 Tant'e` che si sono inventati codice managed ed unmanaged.
Sono d'accordo.
Vc++.net non ha senso di esistere.
Personalmente sostengo che pure 
delphi.net
 sia una cosa un po' bizzarra,
come voler a tutti i costi far migrare a VB.Net le applicazioni VB6.
Ciao
--
Reporting tool: 
http://www.neodatatype.net
Qualunque mentecatto puň scrivere codice che un computer possa capire.


 Ciao
Ciao,
Andrea

 sia la difficoltà a convertirlo in vb. Se riesci a spiegarmelo. 
Ok. Provo. Il C++ strutturalmente può agire sui campi bit-mapped,
mentre VB no. Ecco perché il C/C++ possono essere usati per
strutturare del codice di calcolo che VB non può sognarsi lontanamente.
Ciao,
Andrea

 Potresti anche non riuscire a tradurre il codice.
sì ma non riesco ancora a seguire. Sto parlando di prendere un codice privo 
di puntatori e di trascriverlo in vc e in vb. Sto parlando di prendere un
algoritmo e di tradurlo in un determinato linguaggio.Penso non sia 
impossibile! fatto questo non capisco quale dei due sarà più performante. 
Una volta
di sicuro sarebbe stato vc++ ma con .net quale sarebbe la differenza? non 
posso farlo perché attualmente non ho ancora .net
Eventualmente se qualcuno mi indica come fare per misurare il tempo 
effettivo di esecuzione di un programma in .net ... 

 ha scritto nel messaggio 
news:dCk%d.1089501$35.40...@news4.tin.it...

ok grazie. Questa è una risposta che mi aiuta a capire meglio. Il fatto che 
visual basic
fosse limitato dal punto di vista numerico me ne ero accorto con la versione 
6. Pensavo solo
che con la versione .net l'uso del linguaggio non fosse così prioritario. 
Almeno mi era sembrato di
capire leggendo alcune recensioni. 

 Almeno mi era sembrato di capire leggendo alcune recensioni. 
Le magie del marketing MS.
Ciao,
Andrea

 posso farlo perché attualmente non ho ancora .net
Torniamo al discorso iniziale.
Tutti i linguaggi .Net sono solo uno strato sul framework che alla fine fa
tutto il lavoro.
TUTTI i linguaggi hanno potenzialmente le stesse capacità.
In pratica per alcune finezze, come ti diceva Andrea, alcune capacità non
sono state implementate nel compilatore di alcuni liguaggi.
Praticamente TUTTI i linguaggi vengono compilati in IL, che verrà poi
ricompilato dal FW.
Quindi per una altissima percentuale i vari linguaggi (managed) sono
interscambiabili come sintassi e prestazioni.
Per la translitterazione ad es. ci sono in rete diversi "traduttori" da
vb.net
 a c# e viceversa (personalmente trovo molto buono quello incluso in
#D) anche se in qualche punto occorre sempre l'intervento manuale.


 #D) anche se in qualche punto occorre sempre l'intervento manuale.
ecco questo volevo sentire! quindi da quello che mi dici non importa che 
macchina o linguaggio
usi in linea di massima perché poi alla fine se ne occuperà l'FW di 
ottimizzare la compilazione anche a seconda
della piattaforma utilizzata.
Quindi l'unico ostacolo potrebbe essere la "cattiva" gestione del linguaggio 
nel manipolare ad esempio
i dati numerici o nell'allocazione delle variabili. Quindi un codice 
numerico scritto in fortran ad esempio risulterà sempre più
prestazionale rispetto a qualsiasi altro codice (?). Questo lo dicono gli 
addetti ai lavori. Però secondo me ormai lavorare in c
non fa più alcuna differenza. Magari se qualcuno ha più esperienza in 
merito...
Certo che usare visual basic per fare simulazioni numeriche non dev'essere 
proprio il massimo. Però di sicuro il tempo di esecuzione
deve essersi accorciato di parecchio rispetto alla versione 6. O sbaglio?
L'ho detto male comunque mi sembra questo il senso. E mi pare di capire che 
ciò superi di molto
ciò che si aveva prima con java e che non ci siano paragoni in quanto a 
prestazioni e semplicità.
Mi sembra una gran cosa. Inoltre ho sentito dire che verrà creato un FW .net 
anche per linux. Si sa qualcosa in proposito?

 anche per linux. Si sa qualcosa in proposito?
Si chiama Mono.
Andrea

 Si chiama Mono.
In buona parte già funziona.
Ciao
--
Reporting tool: 
http://www.neodatatype.net
Qualunque mentecatto può scrivere codice che un computer possa capire.


 Ciao
Andrea

 Ora vieni a dirmi che basta il CodeDOM :D
Personalmente penso che se una libreria pensata per .Net non è compatibile
tra applicazioni .Net, il progettista/sviluppatore è un'idiota.
A meno che non sia stato pensato così perchè non vi era altro modo e si sia
rinunciato consapevolmente alla perdita di flessibilità.
Certo, se l'applicazione è scritta da scimmie urlatrici (e spesso è così
:) ) allora le cose si complicano.


 Ciao
Ciao,
Andrea

 manina e se non conosci bene entrambi i linguaggi, sono problemi.
sì questo l'ho capito. Probabilmente parliamo di esperienze diverse.
Io stavo parlando di algoritmi generici. Prendi ad esempio la 
diagonalizzazione di una
matrice. Esiste un algoritmo di base che potrai tradurre in qualsiasi 
linguaggio senza grosse
difficoltà utilizzando 3 sole strutture di controllo (teorema di 
bohm-jacopini). Che tu voglia poi migliorare il codice è un altro discorso. 

> Non conosco 
fortran.net
, ma non ci credo.
non ho parlato di 
fortran.net
 che non conosco ma di fortran puro. A quanto 
dicono gli specialisti per le simulazioni
numeriche il fortran è superiore al C. Ci sono un sacco di benchmark a 
riguardo su internet. Come ripeto non
ne sono molto convinto neanche io. 

 (giustamente, aggiungerei).
Sinceramente fatico a vedere l'uso di puntatori come "caratteristica"
che incrementa le prestazioni... anzi...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Alcune cose che puoi fare con C# con 
VB.NET
 non le puoi fare. 
questo non lo è. O meglio, dipende dal senso che gli attribuisci.
Le sintassi (e le funzionalità) dei due linguaggi sono diverse, quindi
certe cose in una eventuale traduzione dovrebbero essere riscritte in
modo completamente diverso, più lungo e meno efficiente, ma non c'è
assolutamente nulla che possa essere scritto in uno dei due linguaggi
che non possa essere scritto (in modo anche completamente diverso)
nell'altro (ed il discorso si estende a qualunque linguaggio -anche non
.NET).


 Ciao.
Ciao,
Andrea

 modo completamente diverso, più lungo e meno efficiente, ma non c'è
Ed è proprio il senso che intendevo attribuirgli, naturalmente.
Questo perché alla fine si, traduci tutto quello che vuoi(o quasi) in
qualunque altra cosa, ma a che prezzo?
Il discorso è proprio tutto là. Quello che mi dà fastidio(e mi fà
incazzare, molto) è proprio che non si capisca una cosa banalissima:
se vuoi fare la traduzione "liscia" di un linguaggio dotNET in un
altro, devi necessariamente limitarti nel modo di scrivere i programmi.
Cioè, se usi A>B?C:D dovunque(ed imho sarebbe sbagliato), poi vai a
tradurlo in 
VB.NET
 .
Prendi per esempio una categoria di cose importanti, ad esempio
l'overload di metodi ed operatori. 
VB.NET
 non li ha, però sono
utilissimi in tantissime circostanze. Il tuo design, a quel punto,
traballerà perché non avrai usato una cosa specifica di C# che ti
semplifica la vita e rende il tuo design robusto per restare
compatibile con 
VB.NET
 . Il che può valere la pena solo in rari
casi, secondo me.
Ragazzi, ma è possibile che dobbiamo sempre dire ovvietà?
Ciao,
Andrea

 Ciao
Ciao,
Andrea

 codice algoritmicamente uguale, la velocità non cambia(forse :D).
:)
Era quello che volevo dire dal primo post :P
Ciao 

 casi, secondo me.
Se così fosse tutte le librerie .net in giro per il mondo, nonchè lo stesso
framework, sarebbero utilizzabili solo dal linguaggio con cui sono state
scritte.
Comunque a parte le particolarità dei vari linguaggi, a parità di istruzioni
si avrà codice macchina molto simile, quindi prestazioni assimilabili.
Questo è un fondamento della tecnologia .Net.


 Ciao 
Ciao,
Andrea

 Ciao
Ciao,
Andrea

 che incrementa le prestazioni... anzi...
In effetti il tutto dovrebbe già essere gestito in modo trasparente.
Forse (non lo so) in ambienti managed sono pure più lenti perchè devono
forare l'involucro del framework.
Ma considero il discorso sui puntatori come un esempio delle differenze tra
linguaggi e non come caso specifico.


 "verità"(visto che molto spesso, forse troppo, non lo è).
"Marketese"?
Forse intendevi parlare di "markeTTing"? :)
Ciao


 Il tuo design, a quel punto, traballerà...
Concordo...
Ciao e Buona Pasqua...


 forare l'involucro del framework.
Beh... c'è il doppio rallentamento... Uso non necessario di puntatori e
memoria dinamica (tutti gli oggetti sono allocati dinamicamente e
manipolati esclusivamente per puntatore) e codice per gastire in modo
sicuro e trasparente all'utente questi punatatori...
Sarebbe molto più semplice (ed efficiente) evitare di usarli quando non
necessari...



Sě, certamente... ma in ogni caso non utilia velocizzare...


 Ciao.
E Buona Pasqua...
