C++ gestito (C++/CLI) vs C#/VB.NET

Question

Ho lavorato a lungo con C#, tuttavia, sto avviando un progetto in cui il nostro cliente desidera che tutto il codice sia scritto in C++ piuttosto che C#. Questo progetto sarà un mix tra gestito (.NET 4.0) e nativo C++. Essendo che ho sempre preferito C# in C++ per le mie esigenze .NET, mi chiedo se ci siano delle differenze importanti di cui forse non sono a conoscenza tra l'uso di C# e il C++ gestito?

Qualsiasi comprensione di questo è molto apprezzata.

EDIT Guardando Wikipedia per il codice C++ gestito si dimostra che la nuova specifica è C++/CLI e che "C++ gestito" è deprecato. Aggiornato il titolo per riflettere questo.

Answer 1

C++/CLI è un linguaggio .NET completo e, proprio come gli altri linguaggi .NET, funziona molto bene in un contesto gestito. Proprio come lavorare con le chiamate native in C# può essere un interleaving del dolore C++ nativo e Managed C++ può portare ad alcuni problemi. Detto questo, se si sta lavorando con un codice C++ molto nativo, preferirei usare C++/CLI su C#. Ci sono un sacco di trucchi che la maggior parte dei quali potrebbero essere coperti da non scrivere C++/CLI come se stessimo scrivendo C# né scrivendolo come se stessi scrivendo C++ nativo. È la sua stessa cosa.

Ho lavorato su diversi progetti C++/CLI e l'approccio da seguire dipende dall'esposizione di diversi livelli dell'applicazione al codice C++ nativo. Se la maggior parte del core dell'applicazione è nativa e il punto di integrazione tra il codice nativo e quello gestito è un po 'sfocato, allora userei C++/CLI dappertutto. Il vantaggio del controllo nel C++/CLI supererà i suoi problemi. Se si dispone di chiari punti di interazione che potrebbero essere adattati o astratti, suggerirei vivamente la creazione di un livello di bridging C++/CLI con C# sopra e C++ sotto. La ragione principale di ciò è che gli strumenti per C# sono solo più maturi e più ubiquitari degli strumenti corrispondenti per C++/CLI. Detto ciò, il progetto su cui ho lavorato ha avuto successo e non era l'incubo che l'altro ha indicato.

Vorrei anche assicurarmi di aver capito perché il cliente è diretto in questa direzione. Se l'idea è che hanno un gruppo di sviluppatori C++ e vogliono semplificare il passaggio a scrivere codice gestito, vorrei dire al cliente che imparare C# potrebbe essere meno impegnativo di apprendere C++/CLI.

Se il client ritiene che C++/CLI sia più veloce è semplicemente errato poiché tutti si compilano in IL. Tuttavia, se il client ha un sacco di sviluppo C++ nativo esistente o in corso, il percorso corrente potrebbe essere in effetti il ​​migliore.

Answer 2

Ho fatto un progetto con C++/CLI e devo dire era un abominio. Fondamentalmente era un'applicazione WinForms per gestire dipendenti, partite di hockey, scambi tra squadre, calendari ecc, ecc ...

Quindi puoi immaginare il numero di controlli gestiti che avevo sui miei moduli: calendari/raccoglitori data/ora, combo scatole, griglie, ecc.

La parte peggiore era utilizzare solo i tipi C++ per il mio back-end e utilizzare i tipi gestiti per il front-end. Innanzitutto non è possibile assegnare una stringa std a una stringa gestita. Avrai bisogno di convertire tutto. Ovviamente dovrai convertirlo di nuovo ...

Ogni volta che dovevo riempire una griglia, serializzavo le mie collezioni C++ a qualcosa come un vector<std::string>, lo recuperavo nella mia libreria UI e poi lo passavo e lo facevo nuovo DataGridRow per aggiungerli alla griglia. Che ovviamente può essere fatto in 3 minuti con C# e alcuni da Linq a SQL.

Mi sono ritrovato con A + per quell'applicazione, ma sono onesto che sia stato assolutamente risucchiato. Non riesco a immaginare quanto fossero patetiche le altre app per me.

Penso che sarebbe stato più semplice se avessi usato List<Customer>^ (Elenco gestito di qualche oggetto) nel mio C++ invece di convertire sempre tutto tra i vettori di stringhe. Ma avevo bisogno di mantenere il C++ pulito di cose gestite.

/pissedof

Answer 3

Da utilizzare tutte le tre aree (.NET, C++/CLI e C++) posso dire che in ogni modo io preferisco usare .NET (con C# o VB.NET). Per le applicazioni è possibile utilizzare WinForms o WPF (quest'ultimo di cui trovo molto meglio, soprattutto per le applicazioni che sembrano molto più user friendly).

Un grosso problema con C++/CLI è che non si dispone di tutte le funzionalità linguistiche disponibili in .NET. Ad esempio, la parola chiave yield in C# e l'uso di lambda (non credo che sia supportato in C++/CLI) non mi tengano in considerazione).

C'è, tuttavia, un grande vantaggio di C++/CLI. È possibile creare un bridge per consentire a C# e C++ di comunicare. Attualmente sto lavorando a un progetto in cui molti calcoli matematici e algoritmi sono già stati scritti (nel corso di molti anni) in C++, ma la società sta volendo passare a un'interfaccia utente basata su .NET. Dopo aver ricercato varie soluzioni, sono giunto alla conclusione che C++/CLI era di gran lunga migliore per questo. Un vantaggio è che mi ha permesso di creare un'API che, per uno sviluppatore .NET, ha funzionato e ha funzionato proprio come un tipo .NET.

Per lo sviluppo di un front-end di un'applicazione, tuttavia, non consiglierei C++/CLI. Dal punto di vista dell'usabilità (in termini di tempo di sviluppo quando lo si usa), non ne vale la pena.Un grande problema è che VS2010 dropped support for IntelliSense for C++/CLI al fine di "migliorare generale IntelliSense" (penso in particolare per C++). Se non l'hai già provato, ti consiglio senz'altro di controllare WPF per le applicazioni.