Newsgroup: it.comp.programmare.win32
Titolo: passaggio da c++ a c#

Ciao ragazzi...
Si lo so questo è un argomento trito e ritrito.... Ma ho cercato info
sul ng e dintorni e non sono riuscito a farmi un'idea chiara.
In questo momento sto facendo sviluppi sostanziosi sia in visual c
(interamente costruito su GDI windows, senza MFC) che in c# (ma in
ambito web --> 
asp.net
).
Usandoli entrambi ho ben chiare le differenze sintattiche e logiche dei
due linguaggi.
Una cosa non riesco a spiegarmi...
La differenza tra le due tecnologie nello sviluppo di applicazioni
windows... Con VS NET utilizzando c# è ancora possibile scrivere
applicazioni windows come si faeva con c++ (winmain acc. acc.) o il
tutto si è avvicinato di più alle finestre di progettazione di VB?
In pratica non riesco a capire la differenza tra 
VB.NET
 e visual c#....
Spero di essere stato abbastanza chiaro! :)
Grazie a chiunque possa illuminarmi!!!

 c#....
Lo scopo del 
framework.net
 è di appiattire il più possibile la differenza 
tra linguaggi.
Le funzionalità come l'infrastruttura winform, 
asp.net
 etc. sono tutte 
peculiarità definite a livello di framework e non di linguaggio.
Ai linguaggi rimane solo una mera differenza sintattica/stilistica che 
permette di incontrare di più i gusti dei vari programmatori.
Ovviamente ci sono dei "ma" nel senso che CLI (Common Language 
Infrastructure) definisce i requisiti minimi dei linguaggi ma poi i vari 
compilatori sono liberi di ampliare a proprio piacimento una serie di 
funzionalità.
Per questo motivo incontri comunque delle differenze tra i linguaggi che 
rendono preferibile l'uno piuttosto che l'altro. Per esempio se usi Office 
da 
vb.net
 puoi omettere dei parametri nella chiamata a funzioni COM. In C# 
invece non puoi e devi mettere invece "Missing.Value" che rende più "brutto" 
da leggere il sorgente, ma allo stesso tempo più rigoroso (cosa che 
personalmente preferisco).
Altre differenze sono l'uso del codice unsafe (l'uso di puntatori) presente 
solo in C#, oppure la possibilità di usare IJW (=It Just Works) in C++ 
managed extensions che permette di lavorare indifferentemente con codice 
managed e unmanaged.
Infine c'è la bravura dei vari team a creare compilatori più ottimizzati e 
migliori. In questo eccelle il team di VC++ che nella versione 2005 con 
C++/CLI riesce a produrre del codice IL migliore dei colleghi di C# e 
vb.net
.
Per quanto concerne la scrittura di applicazioni win32 la risposta 
ovviamente è no. Se vuoi la comodità dei linguaggi dotnet, devi avere la sua 
infrastuttura sotto, cioè il 
framework.net
.
Sei sempre libero di usare PInvoke da C# e 
vb.net
 per chiamare codice 
unmanaged ma non è certamente la strada migliore se esistono degli 
equivalenti nella base class library del framework perchè solo in questo 
modo potrai sfruttare appieno la più innovativa delle caratteristiche del 
framework, cioè la Code Access Security. Se usi PInvoke il tuo codice girerà 
sempre e solo in full trust mentre per il futuro questo sarà sempre meno 
desiderabile.
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele

Grazie per la risposta...
Mi hai chiarito un po' le idee...
Sai mica dove trovare un bel tutorial o qualche esempio di sviluppo di
applicazioni win32 usando il framework...
Grazie ancora!!!!

 applicazioni win32 usando il framework...
ehm, mi sa che te le ho confuse ancora di piů ...
App win32 (intese come app che usano direttamente le api e non hanno 
dipendenze da altre librerie) non si possono fare con il framework.
Per sviluppare applicazioni Windows tramite il framework, esistono le 
Windows Forms che sono definite nel namespace System.Windows.Forms:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWindowsForms.asp
Se vuoi saperne di piů, parti prima studiando il 
framework.net
, magari con 
il libro di Richter.
Sulle winform puoi cominciare da msdn o da qui:
http://www.windowsforms.com/
Ciao
