Come un C++ stickler, questo mi ha davvero infastidito. Mi è sempre piaciuta l'idea del "framework indipendente dalla lingua" che Microsoft ha inventato circa dieci anni fa. Perché hanno lasciato cadere la palla su questa idea? Qualcuno conosce il ragionamento che sta dietro?Perché WPF non supporta C++ .NET - il modo in cui funziona WinForms?
Parte del motivo è che il supporto C++ è in realtà due lingue in una: le varianti native e CLI; che il carico di sviluppo extra è stato riconosciuto dal team di Visual C++ come la ragione per cui la corretta integrazione di MSBuild è ritardata (ritardi non ho controllato nel 2008 o successivo) dietro altri linguaggi.
Un'altra parte avrà a che fare con la generazione del codice durante la compilazione che prosegue in una build C# per supportare, ad es. la "magia" vincolante; Ho scoperto che anche in F #, non capisci che "sta succedendo".
Anche questo mi dà fastidio, se lo avessero supportato, saremmo in grado di migrare il nostro codice C++ in una nuova GUI molto più semplice ed economico rispetto alla semplice riscrittura di tutto in C#. Ci sta costando una fortuna per rielaborare le nostre app, proprio quello che volevamo in una recessione.
Immagino che il ragionamento sia che C# è popolare (e non come multipiattaforma come C++), quindi hanno deciso di mantenere i loro sforzi di sviluppo al minimo richiesto.
Se fosse il mio ragionamento, sarebbe che C++. Net non dovrebbe essere usato per scrivere GUI.
Non sto cercando di essere snarky qui, forse qualcuno può mostrarmi l'errore dei miei modi ma non penso che sia una buona idea. Sto scherzando con uno in questo momento e lo sviluppo molto più lento rispetto a se l'applicazione è stata scritta in C#. La mia sensazione è che se per l'applicazione sono richieste funzionalità in C++. Net o solo C++ regolare, sembra un'idea migliore sarebbe quella di creare una DLL per eseguire il sollevamento pesante e poter interfacciare con C#.
questo è semplicemente perché C# ha tutto lo sforzo per semplificare. Potrebbero farlo con C++, se lo volessero. Semplicemente no. – gbjbaanb
C'è una buona ragione per? –
C'è un buon motivo per avere un runtime in più lingue, se risulta essere troppo lavoro per supportare la programmazione della GUI in tutte le lingue? –
È possibile eseguire WPF con C++ gestito.
Il motivo è che quasi tutte le nuove applicazioni di programmazione sono ora eseguite in JavaScript, Java, VB.NET o C# - tutti i linguaggi GC. L'enfasi è sulla qualità più elevata per un set di competenze inferiore e C++ richiede troppo dallo sviluppatore, le aziende vogliono che le persone scrivano il codice del bug del registro il primo giorno.
C++ per applicazioni è principalmente per la manutenzione di applicazioni esistenti o dove sono necessarie prestazioni estreme. I driver di dispositivo e il sistema operativo sono ancora spesso scritti in C++, ma anche quelli stanno cambiando (Coyotos è Cbit, E #, Cosmos/Mosa sono C#, Singolarità/Midori).
La mia ipotesi è che il team del compilatore C++ sia a corto di personale, e il mantenimento di due lingue (C++ e C++/CLI) è troppo oneroso. C++/CLI sarà comunque morto con VS11 e scriverò oggetti COM con l'aiuto di estensioni del compilatore leggere, che IMHO è molto più sano (e come .NET friendly come C++/CLI). Preferisco un compilatore corretto per una lingua piuttosto che un compilatore fasullo per due lingue. –