2009-05-04 6 views
62

Sto appena iniziando il mio primo progetto C++. Sto usando Visual Studio 2008. È un'applicazione Windows a modulo singolo che accede a un paio di database e avvia una transazione WebSphere MQ. Praticamente capisco le differenze tra ATL, MFC, Win32 (sono un po 'confuso su quello in realtà) e CLR, ma non riesco a capire come dovrei scegliere.Come decidere se utilizzare ATL, MFC, Win32 o CLR per un nuovo progetto C++?

Uno o più di questi sono solo lì per compatibilità con le versioni precedenti?

È CLR a bad idea?

Qualsiasi suggerimento apprezzato.

Modifica: Ho scelto C++ per questo progetto per motivi per cui non sono entrato nel post, che non sono del tutto tecnici. Quindi, assumendo C++ è l'unica opzione/migliore, quale dovrei scegliere?

risposta

66

Dipende dalle vostre esigenze.

L'utilizzo del CLR fornisce il set di librerie più espressivo (l'intero framework .NET), al costo di limitare l'eseguibile a richiedere l'installazione del framework .NET in fase di esecuzione, oltre a limitare l'utente a la piattaforma Windows (tuttavia, tutte e 4 le tecnologie elencate sono solo Windows, quindi la limitazione della piattaforma è probabilmente la meno problematica).

Tuttavia, CLR richiede l'utilizzo delle estensioni C++/CLI per il linguaggio C++, quindi sarà necessario, in pratica, apprendere alcune funzionalità extra della lingua per poterlo utilizzare. In questo modo si ottengono molti "extra", come l'accesso alle librerie .net, la garbage collection completa, ecc.

ATL & MFC sono piuttosto difficili da decidere tra. Ti riferirei allo MSDN's page for choosing per decidere tra di loro. La cosa bella di ATL/MFC è che non è necessario il framework .NET, solo i runtime VC/MFC devono essere installati per la distribuzione.

L'utilizzo di Win32 fornisce direttamente gli eseguibili più piccoli, con il minor numero di dipendenze, ma è più lavoro da scrivere. Hai la minor quantità di librerie di supporto, quindi stai scrivendo più del codice.

7

Sarei molto curioso sul motivo per cui dovresti farlo in C++. Sulla base della tua breve descrizione, C# sembra una scelta molto più appropriata.

Solo per elaborare un po ', guarda il link che hai fornito descrivendo il C++ CLR. Le note di risposta più votate (a mio avviso, secondo me) che il C++ sia appropriato per "kernel, giochi, app ad alte prestazioni e server" - nessuna delle quali sembra descrivere ciò che stai facendo.

MFC, ATL, ecc saranno supportati nel senso che, sì, sarete in grado di compilare la vostra app sulle future versioni di Visual Studio ed eseguirle su future versioni di Windows. Ma non sono supportati nel senso che non ci sono molti nuovi sviluppi nell'API o nella lingua nello stesso modo in cui sono presenti CLR e C#.

+0

Buona domanda. Fa parte di un progetto più ampio che include alcuni altri pezzi che devono essere in C++ per ragioni legate alla legacy e al vendor. Questa parte non * deve * essere in C++ ma poiché ci sono altre parti che fanno, e poiché questa parte è relativamente piccola, stavo progettando di fare tutto nella stessa lingua. –

+0

C++/CLI (/ clr) può essere molto vicino a C#, se ti piace lavorare in C#, ma vuoi/devi usare C++. La differenza principale è rappresentata da alcune cose di sintassi minore e dal tentativo di evitare l'uso di C++ standard invece delle chiamate CLI. Non c'è davvero alcun motivo per evitarlo. –

+0

E questo non è necessariamente un cattivo pensiero. Tuttavia, continuo a pensare che la cosa migliore da fare sia C# e P/Invoke nelle tue librerie esistenti. Se eri * già * un guru MFC, e questa era solo una piccola aggiunta al tuo progetto, allora sì, probabilmente avrebbe senso continuare in C++. Anche se in questo caso potrebbe essere una buona occasione per ritagliarsi un po 'di "tempo di pratica" con .NET framework – Clyde

18

Win32 è il modo di farlo in modo univoco. È noioso, difficile da usare e ha molti piccoli dettagli che devi ricordare altrimenti le cose falliranno in modi relativamente misteriosi.

MFC si basa su Win32 per fornire un modo orientato agli oggetti per creare l'applicazione. Non è un rimpiazzo per Win32, ma piuttosto un miglioramento - fa molto del duro lavoro per te.

System.Windows.Forms (che è quello che presumo tu intendessi per CLR) è completamente diverso, ma ha grandi somiglianze con MFC dalla sua struttura di base. È di gran lunga il più semplice da usare, ma richiede il framework .NET, che può essere o non essere un ostacolo nel tuo caso.

La mia raccomandazione: Se è necessario evitare .NET, quindi utilizzare MFC, altrimenti utilizzare .NET (infatti, in tal caso, userei C# in quanto è molto più facile lavorare con).

+1

Questo commento è ancora attuale? –

+0

Per Visual Studio 2008, probabilmente - questo è un decennio ora però. In questi giorni, per Windows, stai molto meglio usando WPF. – arke

13

Per quanto riguarda il C++, utilizzerei WTL. È leggero e avrete poche (se vi sono) dipendenze, che lo rendono facile da spedire e installare. Trovo molto soddisfacente quando la mia app è costituita da un singolo EXE che verrà eseguito sulla maggior parte delle versioni di Windows, ma questo potrebbe non essere un problema per te.

Se si sceglie di andare su .NET, C# è quasi sicuramente la strada da percorrere.

Più in WTL qui:

http://www.codeproject.com/KB/wtl/wtl4mfc1.aspx

+1

Useresti ancora WTL? Non ci sono ancora commit per il 2016, ancora. Fonte: [SVN] (https://sourceforge.net/p/wtl/code/631/log/?path=) –

4

Non c'è niente di sbagliato con CLR. Come gli altri qui suggerirei C# ma come hai motivi per attaccare con C++ quindi utilizzare il framework .NET è molte migliaia di volte più facile che fare casino con ATL/MFC se non hai già familiarità con loro (IMO).

Vale la pena ricordare che se si utilizza C++/CLR, in realtà non si utilizza affatto il C++. C++/CLR compila in CIL come C#. Non l'ho mai usato da solo, ma credo che il suo scopo sia quello di consentire la compilazione del codice legacy e renderlo facilmente disponibile per il nuovo codice .NET piuttosto che consentire al nuovo codice di funzionare con i vecchi eseguibili C++. Esistono altri metodi per chiamare il codice nativo da .NET che, forse, dovresti esplorare.

+0

Se devo usare la libreria .NET, preferisco scrivere in C# – Sakura