Qual è la differenza fondamentale tra MFC e ATL?


110

Supponendo che li stia usando solo per programmi GUI "normali" (niente COM, niente ActiveX, niente di speciale), qual è la differenza fondamentale che vedrò tra ATL e MFC, per aiutarmi a capire quale usare?


Ho effettuato alcune ricerche sul Web, ma alla fine nessuna delle risposte ha davvero risposto alla mia domanda:

  • http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80).aspx :

    • "ATL è un modo semplice e veloce per creare un componente COM in C ++ e mantenere un ingombro ridotto. Utilizza ATL per creare un controllo se non hai bisogno di tutte le funzionalità integrate fornite automaticamente da MFC."

      Non risponde davvero alla mia domanda, perché:

      • Non lavoro con COM.

      • Ciò significa che MFC non è veloce? Perché come?

    • "MFC ti consente di creare applicazioni complete, controlli ActiveX e documenti attivi. Se hai già creato un controllo con MFC, potresti voler continuare lo sviluppo in MFC. Quando crei un nuovo controllo, considera l'utilizzo di ATL se non ti serve tutte le funzionalità incorporate di MFC. "

      Inoltre non risponde alla mia domanda, perché:

      • Io non so davvero nemmeno cosa ActiveX è in primo luogo.

      • Sembra che Microsoft stia scoraggiando l'uso di MFC, ma non riesco a capire perché.

      • Che cosa è esattamente la "funzionalità incorporata" di MFC che ATL non fornisce?

    • In generale, questo non risponde alla mia domanda perché non spiega gli svantaggi e le ragioni dietro di essi.

perché direttamente o indirettamente, tutto sembra ricollegarsi alla pagina precedente:

Quello che ho attualmente osservato (negli ultimi due giorni, cercando di imparare entrambi):

  • ATL si basa su modelli o polimorfismo in fase di compilazione.
    • I metodi ATL tendono a essere non virtuali e tendono a restituire riferimenti.
  • MFC si basa su metodi virtuali o polimorfismo di runtime.
    • I metodi MFC tendono a essere virtuali e tendono a restituire i puntatori.

Ma non sembra esserci alcuna differenza architettonica tra loro :

  • Entrambi usano mappe dei messaggi ( BEGIN_MSG_MAPcontro BEGIN_MESSAGE_MAP... un grosso problema)
  • Entrambi racchiudono i metodi Win32 in classi
  • Entrambi sembrano avere classi simili CWndvs.CWindow

Ma poi, se non c'è una vera differenza eccetto per l'aspetto tempo di compilazione e tempo di esecuzione, allora perché esistono entrambi? Uno di loro non dovrebbe bastare?

Cosa mi manca qui?


3
Potrei sbagliarmi, ma so che MFC richiede una DLL di runtime piuttosto pesante, mentre penso che ATL compili tutto in un unico file exe. ATL è in generale più leggero. Inoltre, controlla WTL
Merlyn Morgan-Graham

@ Merlyn: Giusto, ma perché ha bisogno di una pesante DLL di runtime? Qual è la differenza fondamentale che causa questo?
user541686

1
La stessa differenza tra ereditare classi precompilate collegate da una DLL ed ereditare modelli collegati tramite inclusione del codice sorgente / istanziazione del modello. I modelli sono generalmente librerie di "sola intestazione". La mia risposta è incompleta, quindi nei commenti :) MFC esiste ancora a causa dell'enorme adozione e della retrocompatibilità. Altrimenti MS lo avrebbe buttato fuori quando hanno creato i wrapper win32 più recenti. Tendono ad avere contratti di supporto lunghi sul loro software (variabili, ma fino a 10 anni). Il supporto non è incompatibile con la deprecazione, comunque.
Merlyn Morgan-Graham

@ Merlyn: Quindi quello che sto capendo è che non dovrei usare MFC? Cos'è quella "funzionalità extra" che continuano a menzionare? Ne ho bisogno?
user541686

2
@ Merlyn: sentito parlare di ATL.DLL? Sentito parlare del termine "Usa MFC come libreria statica"?
Ajay

Risposte:


179

Penso che la risposta alla tua domanda sia per lo più storica, se guardi indietro a come le due biblioteche hanno avuto origine e si sono evolute nel tempo.

La risposta breve è, se non stai facendo nulla di "stravagante", usa ATL. È ottimo per semplici interfacce utente con COM lanciato.

La risposta lunga: MFC è stato creato all'inizio degli anni '90 per provare questo nuovo linguaggio chiamato C ++ e applicarlo a Windows. Ha reso disponibili funzionalità simili a Office alla comunità di sviluppo quando il sistema operativo non le aveva ancora.

[Modifica abbellimento: non ho lavorato in Microsoft, quindi non so se Office sia mai stato costruito su MFC, ma penso che la risposta sia no. Tornando a Win 3.1, Win 95 giorni, il team dell'interfaccia utente di Office inventò nuovi controlli, li impacchettò in librerie, quindi i team Windows e MFC incorporarono wrapper e API a quei controlli con DLL ridistribuibili. Immagino che ci sia stata un po 'di collaborazione e condivisione del codice tra quei team. Alla fine quei controlli sarebbero entrati nel sistema operativo di base nei service pack o nella prossima versione di Windows. Questo modello è continuato con la barra multifunzione di Office che è stata aggiunta in Windows come componente aggiuntivo ben dopo la distribuzione di Office e ora fa parte del sistema operativo Windows.]

A quel tempo la libreria era piuttosto primitiva, sia perché il linguaggio C ++ e il compilatore erano nuovi, sia perché Microsoft lo costruiva nel tempo con l'evoluzione di Office.

A causa di questa storia, MFC:

  1. Ha un design abbastanza goffo. È iniziato come un involucro leggero attorno all'API di Windows, ma è cresciuto. Ci sono un sacco di piccole "funzionalità" che hanno dovuto essere inventate perché il compilatore e il linguaggio semplicemente non le supportavano. Non c'erano modelli, hanno inventato una classe di stringhe, hanno inventato classi di elenchi, hanno progettato la propria identificazione del tipo in fase di esecuzione, ecc.
  2. Incapsula 20 anni di evoluzione di Office e Windows, che include un intero carico di cose che probabilmente non userete mai: interfacce per documenti singoli e multipli, DDE, COM, COM +, DCOM, collegamento e incorporamento di documenti (quindi puoi incorporare un documento di Word in la tua app se lo desideri), controlli ActiveX (evoluzione dell'incorporamento di oggetti per il web!), Archiviazione di documenti strutturati, serializzazione e controllo delle versioni, automazione (dai primi anni di VBA) e, naturalmente, MVC. Le versioni più recenti supportano l'ancoraggio delle finestre in stile Visual Studio e la barra multifunzione di Office. Fondamentalmente ogni tecnologia di Redmond in 20 anni è lì da qualche parte. È semplicemente ENORME!
  3. Ha un sacco di piccoli trucchi, bug, soluzioni alternative, presupposti, supporto per cose che sono ancora lì che non userete mai e che causano problemi. È necessario avere familiarità con l'implementazione di molte classi e il modo in cui interagiscono per utilizzarle in un progetto di dimensioni decenti. L'analisi del codice sorgente MFC durante il debug è comune. Trovare una nota tecnica di 15 anni su un puntatore nullo che causa un arresto anomalo si verifica ancora. I presupposti sull'inizializzazione di elementi che incorporano documenti antichi possono influenzare la tua applicazione in modi strani. Non esiste astrazione in MFC, è necessario lavorare quotidianamente con le sue stranezze e le sue parti interne, non nasconde nulla. E non farmi iniziare con la procedura guidata di classe.

ATL è stato inventato con l'evoluzione del linguaggio C ++ e sono arrivati ​​i modelli. ATL era una vetrina di come utilizzare i modelli per evitare i problemi di runtime della libreria MFC:

  1. Mappe dei messaggi: poiché sono basate su modelli, i tipi vengono controllati e se si rovina la funzione associata, non si crea. In MFC le mappe dei messaggi sono basate su macro e associate al runtime. Ciò può causare strani bug, messaggi indirizzati alla finestra sbagliata, un arresto anomalo se la funzione o la macro è stata definita in modo errato o semplicemente non funziona perché qualcosa non è collegato correttamente. Molto più difficile da eseguire il debug e più facile da interrompere senza accorgersene.
  2. COM / Automazione: simile alle mappe dei messaggi, COM era originariamente associato al runtime utilizzando le macro, richiedendo molti errori e causando problemi dispari. ATL lo ha reso basato su modelli, compilato con limiti di tempo e molto, molto più facile da gestire.

[Modifica abbellimento: al momento della creazione di ATL, la road map tecnica di Microsoft si concentrava principalmente sulla "Gestione dei documenti". Apple li stava uccidendo nel settore del desktop publishing. "Collegamento e incorporamento di documenti" di Office è stato un componente principale per migliorare le funzionalità di "gestione dei documenti" di Office per competere in questo spazio. COM era una tecnologia di base inventata per l'integrazione delle applicazioni e le API di incorporamento dei documenti erano basate su COM. MFC era difficile da usare per questo caso d'uso. ATL è stata una buona soluzione per rendere questa particolare tecnologia più facile per terze parti nell'implementare COM e utilizzare le funzionalità di incorporamento dei documenti.]

Questi piccoli miglioramenti rendono ATL estremamente più facile da gestire su una semplice applicazione che non necessita di tutte le funzionalità di MFC per ufficio. Qualcosa con una semplice interfaccia utente e un po 'di automazione d'ufficio. È piccolo, è veloce, è limitato dal tempo di compilazione, facendoti risparmiare molto tempo e mal di testa. MFC ha una vasta libreria di classi che possono essere goffe e difficili da lavorare.

Purtroppo ATL ha ristagnato. Aveva wrapper per l'API di Windows e il supporto COM, quindi non è mai andato oltre. Quando il Web è decollato, tutte queste cose sono state dimenticate come vecchie notizie.

[Modifica abbellimento: Microsoft si rese conto che questo "Internet Thing" sarebbe stato grande. La loro road map tecnica è cambiata drasticamente per concentrarsi su Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM / DCOM in Distributed Transaction Server. Quindi il collegamento e l'incorporamento dei documenti non era più una priorità assoluta.]

L'enorme impronta di MFC ha reso impossibile il dumping, quindi si evolve ancora lentamente. I modelli sono stati incorporati di nuovo nella libreria, così come altri miglioramenti del linguaggio e delle API. (Non avevo sentito parlare di WTL finché non ho visto questa domanda. :)

In definitiva, quale usare è semplicemente una questione di preferenza. La maggior parte delle funzionalità di cui hai bisogno si trova nell'API del sistema operativo di base, che puoi chiamare direttamente da entrambe le librerie, se non è presente un wrapper adatto nella libreria.

Solo i miei 2 centesimi basati sull'utilizzo di MFC per molti anni e lo uso ora ogni giorno. Mi sono dilettato in ATL quando è stato rilasciato per la prima volta su alcuni progetti per un paio d'anni. Era una boccata d'aria fresca a quei tempi, ma non andava mai da nessuna parte. E poi è arrivato il Web e me ne sono dimenticato.


Modifica: questa risposta ha una longevità sorprendente. Dal momento che continua a comparire nella mia pagina di overflow dello stack, ho pensato di aggiungere qualche abbellimento alla risposta originale che pensavo mancasse.


39
+1 Vorrei poter +10 questo. Grazie per l'eccellente descrizione della storia: è molto ben scritta e istruttiva! :)
user541686

3
Volevo solo menzionare ... Ho usato MFC per alcuni giorni, poi sono passato a ATL / WTL, che sto usando da un po 'di tempo. Ed è terribilmente fantastico. Non guarderò mai più MFC, probabilmente.
user541686

1
Quindi Microsoft crea nuovi programmi utilizzando entrambi o ha deciso di usarne uno sull'altro?
The Muffin Man

1
Pensavo di conoscere la differenza ... ma non ho mai visto una spiegazione così bella ed elaborata..Ghumbs up..Grazie mille :)
shivi

1
La migliore risposta che abbia mai letto su questo argomento; dovresti farne un articolo che includa WTL
Pat

20

Molte persone che hanno utilizzato entrambi mi hanno detto che la loro esperienza di programmazione è stata meno dolorosa con ATL che con MFC. Il tuo eseguibile compilato sarà anche molto più piccolo con ATL.

Ti consiglio di dare un'occhiata a WTL , poiché si basa su ATL.

Cos'è quella "funzionalità extra" che continuano a menzionare? Ne ho bisogno?

Se si definiscono i requisiti, potrebbe essere più semplice rispondere se si può evitare di utilizzare MFC. Purtroppo "niente di speciale" non è abbastanza esclusivo. Essere inclusivi su quali funzionalità si intende utilizzare potrebbe essere più utile (quali controlli, quali framework / tecnologie / librerie esistenti si desidera utilizzare, ecc.).

Ma ecco un articolo che descrive alcune funzionalità in MFC che non sono direttamente supportate da WTL / ATL.

Anche MFC si è evoluto al punto da supportare molte funzionalità desiderabili, come MAPI, supporto per gli altri requisiti del logo Windows, socket, documenti (se ti piace e / o usi quel modello) e file di documenti composti. WTL ha la sua parte di funzioni interessanti, ma MFC è il chiaro campione di funzionalità. Entrambi gli ambienti supportano le architetture della finestra principale con cornice (finestra con cornice con finestra di visualizzazione separata), applicazioni SDI e MDI, finestre divise, applicazioni basate su dialoghi e varie classi basate su COM per il supporto COM.


3
La risposta di Jay ha questo ritmo. Lasciando questo per il collegamento all'articolo che spiega alcune delle differenze.
Merlyn Morgan-Graham

9

ATL è un insieme di classi pensate per semplificare l'implementazione di oggetti COM.

Puoi usarlo senza MFC. Nel mio lavoro, usiamo ATL per esporre le interfacce COM al codice computazionale. Non è coinvolta alcuna GUI, sta a noi essere in grado di chiamare questo codice computazionale da es. Excel VBA.

Guarda qualche guida / tutorial COM per vedere cosa riassume.

MFC è solo un insieme di classi wrapper GUI per l'API Win32. Guarda alcuni tutorial sull'API Win32 per vedere cosa riassume.


ATL può essere utilizzato anche senza alcun COM coinvolto. Molte classi in esso non hanno alcuna relazione con COM che diventa ancora più pronunciata quando si guarda WTL.
0xC0000022L

1
@ 0xC0000022L: non ero a conoscenza di CWindowImple amici quando ho scritto questo. Ora che ho più esperienza con ATL, potrei provare a riscrivere questa risposta. In particolare, ATL / WTL può sostituire virtualmente tutto MFC.
Alexandre C.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.