C ++. Net è ampiamente utilizzato?

Sono un programmatore C ++ per tradizione. Negli ultimi 12 mesi ho fatto molto codice C # e sono stato piacevolmente sorpreso dall'approccio pragmatico di C # (una volta ho smesso di provare a codificarlo come se fosse "C ++ con garbage collection").

Di recente abbiamo avuto alcuni laureati e quando ho aiutato uno di loro mi sono reso conto che stava usando .Net in C ++. Dopo averle chiesto perché, ha detto che le era stato "detto di usare C ++ dal suo manager". Evidente problema di comunicazione a parte, suppongo che stesse usando .Net perché è l'unico framework a cui è stata esposta.

Mi sono poi imbattuto in un vecchio progetto di uno sviluppatore senior che utilizzava anche C ++ per gestire un front-end di Forms. Ora questo sarebbe stato scritto nel momento in cui .Net apparve per la prima volta, quindi presumo che da parte sua fosse un esercizio di apprendimento giocare con .Net. Era solo una piccola app di utilità.

Avendo dovuto apportare alcune modifiche minori in questa app, mi è sembrato che usare C ++ per guidare .Net ti dia il peggio di entrambi i mondi. Nessuna garbage collection o sicurezza della memoria, ma allo stesso modo nessuna reale opportunità di velocità / ottimizzazione poiché hai a che fare con un framework gestito.

Quindi la mia domanda è se le persone usano C ++ .Net per qualsiasi codice di produzione autonomo di grandi dimensioni (cioè non idraulico) e, in caso affermativo, quali sono i motivi per farlo? Ammetto liberamente di non aver mai approfondito le estensioni di C ++ .Net, quindi potrei fare un disservizio.

C ++. NET (o, appunto, C ++ / CLI) ha ha raccolta dei rifiuti, come ogni altra cosa che funziona in cima .NET. Per raggiungere questo obiettivo pur rimanendo compatibile con il C ++ corretto, utilizza la ^sintassi e gcnewper i puntatori garbage-raccolti ("sicuri").

C ++ / CLI è considerato un abominio da molti, è significativamente più spiacevole lavorare con C # o C ++ vero e proprio, e anche più complicato di entrambi (semplicemente perché porta la complessità del C ++ stesso sul tavolo e aggiunge ciò che serve per funzionare con .NET al mix). L'apprendimento di C # di solito paga anche nell'ambito di un singolo progetto di medie dimensioni. Tuttavia, c'è una cosa che può fare che né C # né C ++ nativo possono fare: compilare C ++ esistente su .NET e farlo parlare con altri componenti .NET.

Di conseguenza, non ha molto senso usare C ++ / CLI per un progetto ex novo: tutto ciò che è collegato a .NET che può essere fatto con esso può essere fatto anche in C #, con una sintassi molto più bella e la sicurezza aggiuntiva di non esporre raw puntatori di default. La sua ragion d'essere più importante sta eseguendo il porting di codebase esistenti su .NET. Una società che decide di iniziare a utilizzare .NET, ma non disposta (o incapace a causa di vincoli di risorse e di tempo) a riscrivere tutti i software che ha prodotto finora, può utilizzare C ++ / CLI per continuare a utilizzare la propria base di codice esistente con modifiche minime, e quindi riscrivere i componenti del loro sistema in C # uno per uno. Almeno questa è la teoria; Non l'ho mai visto in pratica da solo, quindi non posso dire quanto funzioni bene.

Si noti inoltre che C # stesso può interfacciarsi con le librerie native, quindi anche se si devono usare basi di codice C ++ esistenti, non è necessario ricompilarle in .NET: spesso l'interfaccia con loro tramite COM o P / Invoke è la soluzione migliore .