Ho sentito da qualche parte che Microsoft concentrerà i propri sforzi su C# anziché su C++ per la piattaforma .NET. Posso vedere i segni di questo essere vero a causa del progettista GUI che era disponibile per C# ma non C++.C++ .NET sta morendo?
Quindi mi piacerebbe sapere se C++ in .NET sta morendo e se continuerà a essere secondo a C# in futuro.
Se si sta prendendo di mira il framework .NET nello sviluppo di applicazioni, allora sì C++/CLI è un cittadino di seconda classe rispetto a C#. C# è stato specificamente progettato come nella lingua per .NET framework, mentre l'estensione C++/CLI è lì per consentire agli sviluppatori di collegare codice nativo e gestito.
Tuttavia non confondere C++ con C++/CLI (C++ .NET è la stessa cosa ...). Il C++ è vivo e vegeto in aree come il kernel, i giochi, le app ad alte prestazioni e server (ad esempio il server SQL) che è improbabile che cambino. D'altra parte la maggior parte delle 'GUI stuff' di .NET non useranno C++.
Non sapevo che potessi accedere al framework con C++ nativo (è per questo che dici che è la stessa cosa di C++ .NET?). – Unknown
Sta dicendo "C++ CLR" è la stessa cosa di "C++ .NET" – sharkin
È necessario fornire il flag/clr al compilatore C++ se si desidera utilizzare il codice gestito e nativo nello stesso assembly. Fondamentalmente l'aggiunta di questo flag fa sì che il compilatore aggiunga i metadati del framework .NET all'assembly. È anche possibile utilizzare/clr: safe e/clr: flag puri per generare assembly .NET solo MSIL, nel qual caso C# e C++ sono uguali qui (idem per VB.NET, J #, ecc.). – Serguei
Il C++ gestito non è mai stato realmente quello che MS ha pensato che sarebbe stato. C# potrebbe fare (quasi) la stessa cosa, con una sintassi molto più intuitiva e user-friendly.
Oltre a ciò, C++/CLI non verrà lasciato non supportato per un lungo periodo, in quanto è il modo semplice per creare l'interoperabilità tra gli assembly .NET e gli assembly C++ nativi. Questo è tutto ciò per cui è usato (sono sicuro che c'è uno 0,001% di sviluppatori C++/CLI là fuori che non sono d'accordo: P).
Quindi stai dicendo che non puoi fare interop tra C# e C++ nativo? Ho pensato che la cosa p/invoke sia interamente utilizzabile in C# – Unknown
@Unknown non sta dicendo che non puoi, sta dicendo "C++/CLI è il modo semplice". Non so se sarei d'accordo, però, perché nulla in C++/CLI sembra facile per me. –
C++/CLI è sorprendentemente facile ... almeno, rispetto alla riscrittura delle partizioni SDK da zero necessarie per usare P/Invoke. – Shog9
C++/CLI è il modo in cui Microsoft attrae gli sviluppatori C++ nativi su .NET. Era come uno strato intermedio tra C++ nativo e C#, ma sono abbastanza sicuro che gli sviluppatori preferiscano scegliere C++ nativo o C#.
Microsoft non lascerà morire C++/CLI, almeno nel prossimo futuro, tuttavia, senza il supporto della comunità, C++/CLI non sarà in grado di crescere.
In questa generazione, non crescere significa vicino ai morti.
D'altra parte, mi sembra che il mondo della programmazione sia maturato molto, e non mi aspetto una grande crescita nel prossimo decennio. Non c'è motivo per cui una tecnologia significativa non possa sopravvivere a lungo su una base di utenti relativamente costante. –
Ho paura che lo sia.
La ragione di questo non è C# (che non porta niente di speciale e anche se è un nuovo linguaggio non porta a nuove funzionalità del linguaggio, ma solo copie caratteristiche di altri - farmaci generici).
Principalmente perché il primo tentativo di MS di abilitare la piattaforma C++ per .NET - Managed C++ - è stato un disastro.
Dopo questo hanno assunto Herb Sutter, guru C++, che ha reso fantastico la progettazione del lavoro di sostituzione C++ gestita chiamata C++/CLI. Perché e in che misura il design C++/CLI è superiore alla progettazione di C++ gestito, è possibile scoprirlo leggendo A Design Rationale for C++/CLI scritto da Herb.
A proposito, Herb ha reso il compilatore di vc uno dei migliori compilatori conformi agli standard per Windows dopo anni in cui era il peggiore per quanto riguarda la conformità standard.
Penso che le estensioni gestite siano piuttosto buone, migliori di C++/CLI. Sfortunatamente ha aggiunto estensioni divertenti e alla gente non piaceva, così hanno messo diverse estensioni in (sigh) e hanno rotto la possibilità di consumare risorse gestite "nativamente" (cioè sull'heap nativo senza mettere^ovunque). Herb è buono, ma non credo che abbia fatto un ottimo lavoro con C++/CLI. – gbjbaanb
Hai letto "A Design Rationale for C++/CLI"? Da quello che stai dicendo, suppongo che tu non abbia ... –
Er, gbjbaanb, se non sbaglio, le risorse gestite non sono mai state nell'heap nativo. L'operatore^è stato aggiunto per creare una distinzione tra oggetti gestiti e non gestiti, perché prima gli oggetti gestiti erano ancora nell'heap gestito, ma non c'era alcuna sintassi per indicare tale. –
Non penso che stia necessariamente andando via, ma il motivo per cui lo si utilizza deriva quasi sempre dalla necessità o meno dei benefici prestazionali che ne derivano. Se C# può fare la stessa cosa con il 90% dell'efficienza del C++, non è abbastanza buono?
No. È nato morto.È sempre stato trattato come una cita di seconda classe senza una tabella di marcia per la vitalità.
Lease importante sulla vita, grazie a C++/CX la cui sintassi è * molto * simile. Hanno persino aggiunto il supporto IntelliSense. –