Newsgroup: it.comp.programmare.win32
Titolo: .NET versione C++ ?

Da quello che ho capito (anche leggendo su questo NG) pare che ci siano 
due importanti aspetti positivi di .NET e C#:
- la libreria di classi di .NET, ben strutturata, con una valida 
gerarchia object-oriented, decisamente superiore alle Api Win32
- il vantaggio di C# di avere un garbage collector
Il principale svantaggio pare di capire siano le eccessive richieste di 
memoria.
Mi chiedo, non si potrebbero trasferire i vantaggi di sopra al C++:
- creando una libreria di classi C++, che rispetti lo schema delle 
classi .NET
- fornendo una qualche classe che faccia da garbage collector per i 
puntatori che vengono allocati con i new e delete del C++.
...senza cosi' aver bisogno di inventare un nuovo linguaggio, 
semplicemente fornendo al programmatore C++ Windows una buona libreria 
di classi (migliore ad esempio della MFC).
Dan

Mai sentito parlare di C++ Managed?
-- 
Kleidemos
Un computer a un altro quando si incontrano:
"Ciao, come ti boota oggi???"

 di classi (migliore ad esempio della MFC).
Beh meglio di MFC ci vuole poco ed esiste già da parecchio ... si chiama
WTL.
Non capisco poi la reticenza a portarsi dientro il framework. Chi ha
lavorato con VB6 ed MFC si è sempre portato dietro un discreto malloppo di
dll. Il framework è più grosso ma ti da anche molto di più. D'altro canto
chi scrive applicazioni con ATL, WTL o Win32 pure non ha bisogno di nulla ma
paga lo scotto di avere un supporto molto scarno, spesso diepndente dalla
presenza dei common controls (quindi di una versione recente di IE). La
verità è che il supporto base dell'OS non fa più contento nessuno perchè le
Win32 sono vecchie ed è per questo che aspetto con entusiasmo WinFX.
-- 
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://www.ugidotnet.org/2082.blog

 dll. 
Il malloppo che ti devi portare con VB6 o MFC e' decisamente meno pesante
del redist .net (20 e passa MB), e le dll legate a MFC sono quasi sempre
già presenti nel s.o. 
Windows 98, 2000 e XP non hanno integrato .Net, te lo devi scaricare ed
installare. Questa cosa puo' andar bene per l'utente singolo ma in una
societa' con magari 1000 pc (dove pur esiste il setup remoto) questo
aspetto non va sottovalutato, anche perche' un conto è sparpagliare qualche
dll nel proprio sistema (se non si esagera con gli OCX un programma VB6 non
e' cosi' intrusivo), un conto è installare un framework che ti aggiunge un
utente nel tuo sistema, ti cambia le modalita' di logon, ti aggiunge un
applet nel sistema, etc.
Sappiamo bene che con una ricerca su google queste sono cose che si
sistemano, ma dobbiamo ricordarci che l'utente medio puo' andare in panico
per molto meno.
Piu' che reticenza quindi direi "cautela" :-)
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) 
despammed.com

 Piu' che reticenza quindi direi "cautela" :-)
Tu credi che il framework sia più intrusivo degli OCX di VB6? Se è così ti
sbagli.
COM è una tecnologia molto intrusiva perchè ha la pretesa che se installi
l'ultima versione, andrà meglio di quella precedente.
Il framework ha cambiato completamente strategia, installando gli assembly
'side by side' e lasciando che ciascuno usi la versione che preferisce. Mi
fido più ad installare il framework su un production server piuttosto che un
qualsiasi setup di vb6.


 qualsiasi setup di vb6.
Ti do ragione in senso generico, in VB6 trovi progetti che anch'io avrei
paura ad installare sul mio pc (ocx scoosciuti, porcherie varie, etc.)
Come programmatore anche VB6 ho sempre utilizzato quanto presente nel
runtime e pochissimo altro, fatto che in 4 anni di sviluppo mi ha permesso
di ignorare completamente il problema del "DLL hell".
Come ho avuto modo di scrivere in qualche altro post se io un anno e mezzo
fa avessi deciso di passare del tutto a VB.Net avrei perso il 50% dei
clienti, cioe' quelli con il parco macchine datato (PII e 64 MB o anche
meno ma che per i loro attuali usi va bene) e che non hanno intenzione di
upgradare solo perche' il mio programma commissionato sui loro pc sarebbe
lento.
Questo e' il  punto principale, il resto per me sono dettagli ...
