Risposta breve

Dovresti considerare che è un'idea molto rischiosa e costosa che potrebbe non darti tutti i vantaggi che pensi possa essere.

Risposta lunga

Dovresti considerare quanto segue:

C ++ è un linguaggio che può essere usato a un livello molto alto, cioè multipiattaforma (anche se dipende da quanto hai usato le estensioni proprietarie di VC) e per il quale esistono molti strumenti molto maturi. C ++ 11 aggiungerà un bit ancora più succoso per gestire i casi di utilizzo fastidiosi.

Se stai pensando a una riscrittura completa, non dimenticare che riscrivere il codice completamente debug è tempo che non implementi nuove funzionalità. Se non si dispone di un chiaro vantaggio per l'utilizzo di C #, si stanno gettando denaro e tempo attraverso la finestra.

Se il team conosce il C ++, per molto tempo scrivere codice in C # sarà più lento nonostante qualsiasi vantaggio che C # apporti.

Hai due opzioni per la migrazione delle tue app: riavvia da zero (e vedi link , già pubblicato) o aggiungi nuove funzionalità mantenendo uno strato di mappatura tra il codice C ++ e C #. Mentre C # è abbastanza buono per quanto riguarda la chiamata del codice nativo, è ancora un codice piuttosto complesso da scrivere. Se usi P / Invoke o C ++ / CLI, entrambi ti obbligheranno a conoscere molti più dettagli sulla piattaforma di quanto sarebbe necessario per una soluzione C # pura. Inoltre, trascorrerai molto tempo nel marshalling dei dati tra codice gestito e nativo. Un'opzione migliore potrebbe essere COM, anche se spero che ti piaccia la programmazione ATL.

I maggiori vantaggi di C # sono la sua semplicità e il garbage collector che ti liberano dal pensare a molti casi d'angolo. Ciò significa che può essere sviluppato dagli sviluppatori che sono meno hardcore di quello che ti serve per C ++. Nel tuo caso, la tua squadra conosce già il C ++, quindi i benefici sono molto meno presenti. Se usi unique_ptr, shared_ptr, RAII e simili, gran parte della parte pericolosa di C ++ può essere gestita. Sì, hai più possibilità di spararti ai piedi, ma eviti le parti pericolose.

Ma ancora ...

Se non stai parlando di una riscrittura completa, sì, potrebbe essere possibile sviluppare alcuni parte dell'applicazione in C #. Ma sempre tieni a mente il costo del livello di mappatura tra C ++ e C #. Consiglierei di esportare le tue parti C # come moduli COM e di chiamarli dal C ++. Assicurati che porti un vantaggio reale. Se devi costantemente convertire vector<> in IList<> e devi convertire costantemente il tuo tipo C ++ in C #, qualsiasi vantaggio di velocità di C # andrà perso. Guadagni gran parte della conversione in C # e .NET quando tutto può rimanere all'interno del CLR. Ottenere tutto all'interno del CLR significa una completa riscrittura di un'applicazione complessa e questa è una proposizione pericolosa.

Tutto sommato, non lo consiglierei.

Sembra che stai per prendere un sacco di decisioni davvero pessime.

Highlight the development time is comparatively lesser in C# than C++.

Sembra sospetto incredibilmente . Non è certamente vero se il tuo team conosce il C ++ ma non conosce C #, per esempio.

I feel there are many features in C# like Collections, Generics, and other libraries which can be used to build the current application in a better and efficient way.

C ++ ha sicuramente quelle cose e in effetti i generici sono più facili in C ++ di qualsiasi altra lingua. Sembra che tu abbia appena sentito da qualche parte che C # è migliore, quindi vuoi passare settimane a riscrivere tutto in C #, quindi non essere più bravo a fare cose in C # di quanto non lo sia in C ++. Inizia con STL e potenzia ...

Use a Design pattern, which will help us to maintain the application in a better way.

Sembra che tu non abbia idea di cosa sia un modello di design.

Per farla breve: non puoi creare un caso di ingegneria del suono basato sul sentito dire. Devi farcela con le conoscenze tecniche.

We currently have a complex VC++ software application, which uses a library like ObjectARX to build the dll. I feel there are many features in C# like Collections, Generics, and other libraries which can be used to build the current application in a better and efficient way.

_{(Nota: ObjectARX è l'API di estensione per AutoCAD, quindi OP sta chiedendo di un'applicazione specifica di un dominio che richiede conoscenze specializzate nel dominio approfondito.)}

Fai un respiro profondo e chiediti se la complessità del software proviene dal dominio (progettazione assistita dal computer e geometria computazionale) o dalla scelta della lingua. Se la complessità deriva dal dominio, cambiare la lingua potrebbe non rendere il tuo lavoro più semplice.

Caso in questione, usando un esempio stupido: un Polygon non è lo stesso di IList<Point2> . In che modo un IList sa come verificare la presenza di punti ripetuti? Segmenti che si intersecano? Incorporare un poligono 2D complanare in un piano nello spazio 3D?

Occasionalmente, la mancanza di zucchero sintattico in alcune lingue complicherà davvero lo sviluppo del software specifico del dominio. Un primo esempio è la funzione lambda. Con C ++ 11 questi zuccheri sintattici essenziali possono essere utilizzati per semplificare e modernizzare il codice. In questo caso, la modernizzazione del codice C ++ potrebbe essere una scelta migliore rispetto alla migrazione a C #.

_{Un'altra osservazione ad altri lettori: ogni versione di ObjectARX per Visual Studio è legata a una versione specifica di Visual Studio e non è compatibile né con le versioni precedenti né con quelle successive. A partire da ObjectARX 2013, è richiesto l'uso di VS2010 SP1. (Pertanto, OP non può facilmente raccomandare l'uso di VS2012 a meno che il venditore non rilasci una nuova versione di ObjectARX e il cliente (datore di lavoro dell'OP) vi aggiorni.) link}

_{Fortunatamente, VS2010 SP1 supporta anche un utile sottoinsieme (ma non tutti) della sintassi C ++ 11. In particolare l'iteratore for-loop semplificherebbe un po 'il codice appena scritto. Tuttavia, il vantaggio potrebbe non giustificare la modifica del vecchio codice.}

I have been thinking about it, but I am not sure on how to present it to my Supervisor and colleagues.

Il modo migliore è chiedere solo in modo informale al proprio supervisore (idealmente l'architetto del software). È suo compito tenere d'occhio ogni possibilità, comprese le scelte di piattaforma, le migrazioni e la fattibilità a lungo termine del progetto.

_{Se effettivamente ti trovi più esperto del tuo supervisore / architetto del software (che è altamente improbabile), trova un altro lavoro.}

I would appreciate any help, to help me think in the right direction and highlight the points to bring it to the team.

Il mio suggerimento:

Roman wasn't built in a day.

In qualsiasi momento della tua ipotetica re-implementazione, l'applicazione nel suo insieme deve essere dimostrabile (almeno eseguibile e verificabile). Quindi, conterrà parti scritte in VC ++ e parti scritte in C #. Se puoi dimostrare che l'applicazione funziona ancora in modo soddisfacente (senza grossi problemi, problemi o inefficienze), hai trovato un "percorso nella giungla" dal presente del C ++ del progetto al futuro di C #.

Un foglio di lavoro di esempio:

• Supponiamo che il 5% del progetto sarà migrato in C #.
  • Quali moduli o componenti del progetto sceglieresti di eseguire la migrazione a C #?
  • In che modo interagiscono con il resto dell'applicazione?
  • Prevedi qualche difficoltà?
• Ripeti la domanda per il 20%, 40%, 60%, 80% e 99%.

Un'altra importante domanda da porsi:

• Ci sono altri team in azienda (o clienti paganti) che dipendono dall'applicazione in C ++? Questi team accetteranno di migrare anche a C # o il tuo team sarà in grado di fornire l'interoperabilità per quel team?

Se hai fatto questo, presenta le tue scoperte all'architetto del software, che sarà quindi responsabile dell'identificazione dei blocchi stradali nelle restanti sezioni di questo percorso nella giungla.

Se non sai come C ++ e C # possono interoperare ... _{Ti suggerisco di chiudere la domanda APPENA POSSIBILE prima che un torrente di downvotes brucino i tuoi punti di reputazione guadagnati duramente ...}

Ho fatto alcune applicazioni in C ++ e alcune in C #.

Certo, C ++ può essere più complesso di C # e C # ha LINQ, garbage collection ecc. Tuttavia, funzionalità come Collections e Generics sono disponibili anche in C ++, per favore dai un'occhiata a STL, Boost e C ++ 11.

"Modernizzare" il tuo codice C ++ mi sembra la scelta migliore, ad es.

• utilizzando contenitori come std :: list e std :: vector al posto di C-array
• evitando puntatori normali quando possibile e passando a std :: shared_ptr ecc.
• usando std :: string invece di char *
• Boost fornisce una libreria per quasi tutto
• ecc.

Dovresti evitare di usare sia C ++ che C # nella tua applicazione (CLR o P / Invoke), a meno che non sia assolutamente necessario, ad es. La DLL per un dispositivo è scritta in C ++ e l'applicazione è stata eseguita in C #. Il livello di mappatura ti causerà mal di testa.

99 volte su 100, è meglio rifattorizzare il codice piuttosto che riscriverlo da zero.

Per quanto riguarda il reimplementing in un'altra lingua: fai dannatamente SURE che i benefici superino i costi e i rischi, sia a breve che a lungo termine. A proposito: con l'aumentare delle dimensioni e / o della complessità dell'applicazione, le possibilità che questa decisione abbia senso vanno giù.