Domanda

    

Questa domanda ha già una risposta qui:

         

Ho lavorato come programmatore nativo C ++ negli ultimi anni. Ora stiamo iniziando un nuovo progetto da zero. Allora, cosa ne pensi di passare a C ++ \ CLI a costo di perdere il codice indipendente dalla piattaforma. Ci sono dei vantaggi speciali che si possono ottenere passando a C ++ \ CLI?

È stato utile?

Soluzione

Vorrei raccomandare quanto segue, in base alla mia esperienza con C ++, C # e .NET:

  • Se vuoi andare nel modo .NET, usa C #.
  • Se non si desidera .NET, utilizzare il C ++ tradizionale.
  • Se devi collegare il C ++ tradizionale con il codice .NET, usa C ++ / CLI. Funziona sia con .NET che chiama le classi C ++ che con C ++ che chiama le classi .NET.

Non ho senso andare semplicemente in C ++ / CLI se non ne hai bisogno.

Altri suggerimenti

Alcune domande da considerare prima di passare:

[1] Stai bene con l'adesione a Windows? Esistono cloni .NET per altri sistemi operativi, ma la tua app non funzionerà in modo trasparente. Una complessità che potresti non aver bisogno.

[2] Stai pensando di passare solo per il supporto della garbage collection? In tal caso, puoi semplicemente utilizzare alcune librerie C ++ Garbage Collector. E se scopri come sfruttare std :: shared_ptr, potresti non sentire il bisogno di garbage collector. Un sovraccarico che potrebbe non essere necessario.

[3] Stai considerando C ++ / CLI a causa della garbage collection & amp; tutte le utili classi .NET che puoi sfruttare? In tal caso, perché non passare semplicemente a c #. C ++ / CLI è una tecnologia di transizione ed è meglio non investire risorse in tali cose. c # sta diventando abbastanza maturo e utilizzabile.

Personalmente, mi limiterei a seguire C ++;).

C'è qualche vantaggio per te? Probabilmente perderai la possibilità di passare a un altro sistema operativo.

non preoccuparti se non ti stai integrando con le app .NET. Certamente non usare STL / CLR poiché le sue prestazioni sono davvero orribili.

Sta tentando di capovolgere questa opzione per usare le librerie di classi .NET, ma ci sono alternative. Se lo fai, non sarai in grado di trasferire il tuo codice così facilmente.

Sembra anche che l'ascesa di OSS sia in aumento, quindi ora potrebbe essere il momento di investigare utilizzando librerie e strumenti multipiattaforma. Puoi distribuire un'app Linux molto più facilmente di una Windows (inviando un sistema operativo completamente configurato!) E otterrai un ROI molto migliore se distribuisci client Linux (poiché sono gratuiti).

Se fossi un uomo d'affari, vorrei almeno avere la possibilità di implementare su Linux o Mac che solo su Windows. Strategicamente, non vorrei scommettere che il mondo rimase con Microsoft tra 5 anni.

Il principale vantaggio che potresti passare al C ++ / CLI è quello di ottenere l'accesso alle librerie .NET e al framework stesso (garbage collection ecc.). Tuttavia, per quanto ne so, il motivo principale per cui esiste C ++ / CLI è facilitare il porting del codice C ++ esistente da eseguire in .NET framework. I nuovi progetti sono incoraggiati a utilizzare C #.

Se hai bisogno di usare il codice C ++ esistente mischiato con il framework .NET, allora avrebbe senso usare C ++ / CLI, ma in generale dovresti iniziare con C #.

Se in .NET è presente qualcosa che il nuovo progetto deve utilizzare ampiamente (magari con un design della GUI più semplice o qualcosa del genere), utilizzare C #. in caso contrario, attenersi al C ++ nativo. Non credo che perderai nulla facendo questo.

Non mi piacciono così tanto C ++ / CLI che consiglierei di chiarire, come descrivo qui . Alcuni suggeriscono di usare C ++ / CLI come bridge tra C ++ standard e C #, ma grazie al modo in cui è progettato C ++ / CLI, è molto noioso usarlo in questo modo (è necessario creare manualmente wrapper del normale codice C ++ che può essere chiamato da C #). Pertanto, raccomanderei SWIG invece di interfacciare lo standard C ++ con C # (anche se, certamente, SWIG ha una curva di apprendimento sostanziale ).

Dai un'occhiata a questi due articoli:

Una panoramica critica di C ++ / CLI, Parte I

Una panoramica critica di C ++ / CLI, Parte II

  

Credo che ormai lo sei   come sono convinto che C ++ / CLI sia   né un "insieme di estensioni a C ++"   (per molti aspetti è in realtà un   sottoinsieme di C ++), né è correlato a   C ++ più di qualsiasi altra lingua con   punti e virgola e parentesi graffe.   Inoltre, C ++ / CLI è sicuramente un   Linguaggio di programmazione orientato a Windows;   non è sicuramente una lingua che a   Server Solaris 10 o un cellulare Nokia   il telefono sarà felice di funzionare. Cosa fa   ha qualcosa a che fare con il C ++?

Uno dei principali svantaggi dell'utilizzo di C ++ / CLR è la possibilità di perdere il proprio IP (proprietà intellettuale) se il codice non viene oscurato sufficientemente. In generale, sono d'accordo con le dichiarazioni fatte da altri membri qui. Se vuoi un codice portatile indipendente da MS .net vm, allora C / C ++ nativo è la strada da percorrere.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top