Per favore, descrivi la tua esperienza nell'uso di Microsoft C++/CLI

Question

C++/CLI è un linguaggio molto potente. È l'unico linguaggio CLR in cui è possibile combinare perfettamente il codice gestito e non gestito. Quanti sviluppatori di software (su questo sito) stanno usando questo linguaggio? In che tipo di progetti lo usi? È un adattamento del codice legacy o la creazione di un software originale? Puoi confrontare il vecchio C++ gestito con il nuovo C++/CLI? Cosa ne pensi della qualità attuale e del futuro di C++/CLI?

Answer 1

Ho usato C++/CLI per un progetto di simulazione. Il mio motore di simulazione che esegue il calcolo reale era una base di codice esistente scritta in C++. Avevo bisogno di avere un front-end per la GUI, che ho codificato con successo in C++/CLI.

Dal mio punto di vista, la lingua è altrettanto facile da codificare come C# anche se con un leggero imbarazzo sintattico. Detto questo, la sintassi è molto più semplice di quella cosa gestita dalle estensioni gestite da Microsoft in precedenza.

Una delle funzionalità più potenti di C++/CLI deve essere la possibilità di ricompilare semplicemente il codice C++ nativo esistente in MSIL. Naturalmente ci possono essere singhiozzi, ma per la maggior parte delle applicazioni dovrebbe essere un esercizio senza problemi.

Per quanto riguarda l'idoneità di C++/CLI, penso che rimarrà strettamente un linguaggio per l'interoperabilità con C++. Se stai scrivendo un'app completamente nuova, non c'è assolutamente alcun motivo per scegliere C++/CLI su, ad esempio, C#. Come ho detto, lo è un po 'più scomodo da usare rispetto al secondo.

Answer 2

C++/CLI era straordinariamente semplice per portare il CLR into FreeSWITCH. Molto più semplice rispetto all'API di hosting o all'utilizzo di Mono.

L'ultima volta che ho utilizzato C++ gestito era nel 2003 o giù di lì. Ricordo che è un po 'un dolore e non funziona perfettamente.

Answer 3

L'ho usato per scrivere strati sottili di integrazione tra codice gestito e nativo. Questo è tutto però.

La caratteristica unica più noto di esso è la capacità di approfondire perfettamente in codice non gestito e modificare (o accidentalmente danneggiato) qualsiasi po 'di memoria scrivibile in tutto il processo - che non è un vantaggio nella programmazione generale, ma quando serve , è ottimo. Ma penso che ne avrò bisogno sempre meno. Puoi compilare C++/CLI con un flag/pure, ma poi diventa davvero una lingua completamente nuova.

Ci sono altre due grandi caratteristiche uniche però:

• distruttori che fare qualcosa di utile. In C# un distruttore è un finalizzatore. In C++ è un distruttore definito deterministicamente corretto. Ciò significa che C++/CLI ha l'infrastruttura più completa per lavorare con IDisposable. C# aiuta solo i clienti (attraverso lo usando la dichiarazione), ma solo C++/CLI aiuta anche gli implementatori. Sono fiducioso che forse un giorno C# assorbirà questa funzionalità.

• Modelli di duck-typing, che possono essere utilizzati insieme ai generici CLI. Un'altra cosa che sarebbe molto utile in C#, anche se potrebbe essere fatta molto più facilmente senza il bagaglio storico.

Ma C# è abbastanza buono senza le ultime due cose che non sono tentato di usare C++/CLI in generale.

Answer 4

Usiamo ampiamente C++/CLI.Lo abbiamo usato per trascinare una vecchia applicazione MFC nell'era .Net, così ora possiamo scrivere la maggior parte delle nuove funzionalità in C# e integrarlo con il codice MFC legacy usando C++/CLI, sia eseguendo il wrapping delle classi native sia scrivendo nuovi oggetti business gestiti . Nei nostri vecchi assembly, stiamo ancora scrivendo nuove funzionalità anche in C++/CLI.

Non ho esperienza con "managed C++" ma C++/CLI è una gioia da usare rispetto a MFC e Visual C++. . Ha una sintassi molto più pulita rispetto a C++ o Visual C++ gestiti e non abbiamo avuto alcun problema nel far sì che anche gli sviluppatori junior potessero accelerare.

Ci sono pochi comportamenti interessanti in C++/CLI come quando si passa un oggetto nativo in un metodo su una classe gestita, si mette un sottile involucro gestito attorno all'oggetto nativo (invisibile allo sviluppatore) solo per lo scopo di fare la chiamata, ma quello shim è privato in modo così assertivo da non poter essere chiamato dall'esterno. Ci sono modi per aggirare questo, come sempre, ma ci ha colto un paio di volte all'inizio.

Utilizziamo Visual Assist X per il supporto del refactoring (accettabile), MbUnit/Gallio per il test dell'unità delle classi gestite e NMock o RhinoMocks per il nostro framework di simulazione.

Nel complesso, direi che il linguaggio ha salvato il nostro prodotto e ci consente di sfruttare tutte le novità eccitanti che accadono nel mondo dello sviluppo. Se stessimo ancora utilizzando solo Visual C++/MFC, avremmo difficoltà a reclutare sviluppatori e ad essere molto più limitati nella scelta di COT di quanto non stiamo usando .Net.