Newsgroup: it.comp.lang.c++
Titolo: MFC vs NET

Buongiorno a tutti, non so se � il posto pi� appropriato per questo 
messaggio ma ci provo comunque, premetto che non voglio guerre di religione 
ma voglio capirne solo pregi e difetti delle due soluzioni.
Devo portare un software vecchio di quasi trent'anni da interfaccia grafica 
proprietaria in interfaccia windows (utilizzare finestre e controlli 
standard), altre applicazioni che utilizza questa azienda sono sviluppate in 
MFC.
cosa consigliereste di utilizzare? quali pregi e difetti trovate nelle due 
opzioni?
- MFC � pi� performante?
- .Net � di pi� facile decompilazione?
altre soluzioni?
il software manipola immagini di grosse dimensioni (siamo passati a 64bit 
per i limiti di RAM del 32bit)
Grazie 

 
e un software di 30 anni fa usava piï¿œ di 4gb di ram? :-)
Se ï¿œ un discorso di performance puro direi mfc rispetto a .net, se vuoi
usare .net da C++ devi usare il managed c++ che oltre non essere
standardm elimina alcune caratteristiche (ad esempio derivazione
multipla), la gestione heap delle classi viene delegata al runtime (che
usa un meccanismo di reference) e la dichiarazione deve essere preceduta
dalla macro __gc, potrei continuare, ma sinceramente se devi usare .net
usa C#, il managed C++ ï¿œ una cacata pazzesca.
Per quanto riguarda le performance con mfc eviti: gestione dello heap
delegata ad garbage collector, compilazione in codice intermedio (poi
passato ad un jit) e altro.
Secondo me se posso esprime un parare ti conviene:
primo passo=> slegare completamente l'applicazione dalla gui
secondo passo=> fare in modo che compili ansi strict
terzo passo=> riprogettare una gui con mfc (o wxwidgets o simili)
ma volevi direi 3 anni o davvero 30anni?

 per i limiti di RAM del 32bit)
.NET ha il pregio che l'eseguibile e' indipendente dalla lunghezza di 
word di hardware e sistema operativo, e quindi e' possibile consegnare 
un unico eseguibile che funziona in modo efficiente su sistemi a 32 bit 
e che sfrutta tutta la RAM disponibile su sistemi a 64 bit. Invece con 
MFC si deve realizzare un eseguibile a 32 bit e un altro eseguibile a 64 
bit.
Io comunque sconsiglio l'uso di C++ per applicazioni .NET in quanto non 
fornisce nessun vantaggio e ha qualche svantaggio rispetto a C#.
 > altre soluzioni?
Dipende da quale linguaggio si vuole usare e da quali piattaforme si 
vuole supportare.
Io consiglio o C# con .NET, o C++ con QT.
in ogni caso consiglio di mantenere ben distinta la logica di 
interfaccia utente dalla logica di elaborazione o di interfaccia con 
altre applicazioni e altri sistemi, in modo da poter testare ed 
eventualmente sostituire i singoli moduli.
-- 
Carlo Milanesi
http://digilander.libero.it/carlmila

 ma volevi direi 3 anni o davvero 30anni?
Trent'anni si fa per per dire ma almeno venti-venticinque li ha tutti, lo 
sviluppo � sempre continuato ma ormai ha bisogno di una riprogettazione 
completa! 

 
http://digilander.libero.it/carlmila
 

 soprattutto per quanto riguarda il DEBUG.
Ci sono almeno due possibilitï¿œ consigliabili:
* Usare Visual Studio con una libreria diversa da MFC (come QT, WTL, 
wxWidgets).
* Usare QT Creator con la libreria QT. QT Creator contiene un debugger 
visuale. Siete giunti alla conclusione che non e' in grado di eguagliare 
il debugger di Visual Studio?
MFC, oltre a essere obsoleto, e' proprietario, e questo vi vincola al 
produttore e alla piattaforma. Se un giorno decidessero di non 
supportarlo piu' rimarreste con un prodotto abbandonato, come e' 
successo con chi sviluppava con Visual Basic 6.
