GUI .NET - C# vs C++/CLI

Question

Sto scrivendo una piccola app che richiede alcuni listbox, pulsanti, caselle di testo. Sarà collegato con Boost, MySQL, ecc. Libie statiche C++. Il progetto richiede funzioni win32. Immagino che Winforms andrà bene (MFC e CodeJock richiedono troppo tempo).

Quindi C++/CLI sembra perfetto per il lavoro. Basta usare il C++ standard sul lato della GUI. Poi mi imbatto in thread che suggeriscono di scrivere la tua GUI in C#. Quindi utilizzare p/Invoke (lento) o un'interfaccia C++/CLI alle DLL C++ standard.

Esempio: http://social.msdn.microsoft.com/Forums/en-US/clr/thread/6ae877ac-07b4-4d26-8582-de475ee9a5cb

Perché? Che vantaggio c'è nell'usare C# per la tua GUI winforms invece di C++/CLI (sembrano uguali, i comandi sono gli stessi). Quale svantaggio c'è nell'utilizzo dell'eseguibile C++/CLI invece dell'eseguibile standard C++. Posso capire se la compatibilità tra piattaforme è stata un problema, ma in questo caso non è stato possibile utilizzare le funzionalità gestite (oltre alla GUI).

Non capisco perché si dovrebbe usare C# e quindi andare così lontano per separarlo con una "DLL del motore". A meno che, naturalmente, la "DLL del motore" sia stata utilizzata anche per altre applicazioni.

Grazie

Answer 1

penso che la maggior parte delle raccomandazioni per quanto riguarda questo centro domanda intorno al fatto che C# è solo un ambiente migliore per creare applicazioni .NET con oltre C++/CLI. La sintassi è più pulita, gli strumenti sono migliori - sia in Visual Studio che da terze parti. Otterrai un supporto sempre migliore da parte degli sviluppatori che conosceranno quasi tutti C#.

Le applicazioni C++/CLI sono abbastanza diverse dallo standard C++ con tutti quei caratteri^e% che almeno io ritengo NON sia C++.

La maggior parte dei consigli viene anche dal punto di vista che si desidera creare un'applicazione .NET e C++/CLI viene utilizzato più come un livello di colla. Ogni volta che ho usato C++/CLI, è stato a malincuore e quasi sempre perché alcune librerie di terze parti avevano molti oggetti C/C++ complessi che trasmetteva. Quando usi C# e P/Invoke, devi spesso creare classi per rispecchiare le strutture e le classi presenti nei file di intestazione C++ del software con cui stai interagendo. Mantenere quelli in sincrono è laborioso e fare errori è facile da fare. Inoltre, capire come eseguire il marshalling di una struttura con i puntatori alle strutture di array di struct farà sciogliere il tuo cervello!

Il mio consiglio generale è di usare C# (o VB.NET) per creare tanto codice che è possibile per la vostra applicazione. Utilizzare P/Invoke quando la necessità di chiamare l'API Win32 e/o SDK di terze parti è limitata e le interfacce e i parametri sono semplici. Usa C++/CLI come strato di colla quando questo non è possibile.

In un ambiente di squadra, i tuoi colleghi sviluppatori ti ringrazieranno per aver limitato l'utilizzo di C++/CLI solo dove è assolutamente, positivamente richiesto. La competenza C++/CLI non è così comune.

Answer 2

Mi sono chiesto, quindi con Visual Studio 2008 ho creato un nuovo progetto di applicazione Windows Form utilizzando C++/CLI come lingua. La prima cosa che ha fatto è stato un errore. Quindi l'ho preso come un'indicazione che questa roba non è ancora pronta per l'uso. Forse non sto dando abbastanza possibilità!

The file 'c:\source\Test\Test\Form1.h' does not 
support code parsing or generation 
because it is not contained within a 
project that supports code. 

Questo accade ogni volta che provo ad aprire il file Form1.h wizard-creato.

Answer 3

Personalmente, adoro C++/CLI, ma preferisco scrivere la mia interfaccia utente in C#.

C++/CLI è ottimo per lavorare direttamente con Win32 o parlare con codice legacy, ma è un po 'troppo prolisso per i miei gusti quando si tratta di codice UI. Il codice UI di WinForms in C# è bello e semplice (per la maggior parte, haha). Scrivere codice UI in C++ è quasi sempre disordinato (basta guardare MFC).

Perché non creare l'interfaccia utente in un unico assembly C# e inserire tutto il codice di livello inferiore in un assembly C++/CLI? La cosa bella di C++/CLI è che puoi creare un livello gestito che il tuo codice C# può facilmente chiamare. Quel livello gestito può quindi inoltrare facilmente le chiamate a un livello nativo di codice C++ o C lineare.

Answer 4

Che vantaggio c'è ad utilizzare C# per il vostro WinForms GUI invece di C++/CLI (hanno lo stesso aspetto, i comandi sono gli stessi)?

Non hanno lo stesso aspetto. C# è a mio parere più pulito e ha alcune utili astrazioni. Anche il supporto degli strumenti è notevolmente migliore per C# o VB.net.

Look here for an example comparison

e non dimenticate caratteristiche del linguaggio produttivi come Lambda Expressions, LINQ, inferenza di tipo, ecc, che tendono a colpire C# prima e trickle down a VB.net abbastanza presto ma raramente trovare la loro strada verso il basso per C++/CLI.

Answer 5

Sto scrivendo una piccola app che richiede alcuni listbox, pulsanti, caselle di testo. Sarà collegato con Boost, MySQL, ecc. Libie statiche C++. Il progetto richiede funzioni Win32 ...

io probabilmente ottenere rischio da downvoted, ma, se la maggior parte del codice è già scritto in C++ e utilizzare la funzionalità C++, woudn't che sia più semplice per scrivere il vostro GUI in nativo C++.

Non è necessario utilizzare MFC per creare GUI. Dai un'occhiata a Qt4, hanno un ottimo tutorial così puoi iniziare a scrivere GUI in C++ con poche ore.

Answer 6

Sì, sembra che la maggior parte delle persone suggerisca automaticamente l'uso di C# su C++ presumendo che tu conosca già C# o che sia disposto a investire del tempo per apprenderlo. Non vedo cosa sia l'odio per C++/CLI WinForms. Almeno se si desidera eseguire il porting su un codice C++ esistente, il lavoro viene completato. Almeno ho virato su una GUI al mio C++ esistente usando WinForms/CLI. Sì ho probabilmente usare C# se stavo iniziando da zero, dal momento che:

1 so già C

2 So che è molto più facile e più veloce da codice utilizzando C

Ma come ho detto, se si hai già ottenuto il codice C++ che ti circonda, vuoi davvero ripartire da zero?