Perché WinRT non è gestito? [chiuso]

164

Windows 8 introduce WinRT, che è come .NET ma non gestito. Perché non è gestito? È un problema di prestazioni? Significa che la garbage collection non è adatta per le API di livello inferiore?

c# .net windows-8 windows-runtime

— user380719
fonte

Era una brutta telefonata , tanto brutta quanto chiuderla. Ora insisti su riferimenti e fonti, lo hai interrotto prima chiudendo la domanda. Ora hai eliminato eccellenti fonti, dai programmatori che ci hanno lavorato.

— Hans Passant,

Ho votato fuori tema poiché questo non affronta una questione di programmazione pratica. È solo curiosità. Nessun programmatore cambierà il proprio codice a seguito di questa domanda.

— Raymond Chen,

@Kev Con questo ragionamento, domande come "come è stato formato il pianeta Terra?" sarebbe stato assolutamente terribile nella comunità scientifica perché attirava molte speculazioni religiose. Ci sono buone risposte a questa domanda - solo perché attira molte cattive risposte non significa che sia una cattiva domanda. Davvero, perché non spostare questa domanda su P.SE?

— Rei Miyasaka,

@casperOne È una domanda "lavagna" legittima per molti sviluppatori: vogliamo conoscere i motivi presumibilmente tecnici della decisione, in modo da poter applicare lo stesso ragionamento altrove. È perché il Garbage Collector è difficile da profilare? È perché consente un accesso più semplice alle astrazioni hardware di livello inferiore? Se non ci sono ragioni tecniche, è semplicemente sfortunato, ma non ha nulla a che fare con la qualità della domanda stessa.

— Rei Miyasaka,

Sono d'accordo, con @HansPassant; questa domanda deve essere riaperta e trattata come valida. "Perché non è gestito?" è un'ottima domanda rispetto ai fondamenti di WinRT.

— Rob Perkins,

Risposte:

190

WinRT è un sostituto per l'antico Winapi basato su C. È un API che deve essere utilizzabile in molti ambienti di runtime. 20 anni fa, un API era relativamente facile da interagire. Da allora, COM è diventata la colla universale nell'ultima metà degli anni '90. Praticamente qualsiasi runtime di lingua di uso comune in Windows supporta COM.

Un garbage collector è un dettaglio dell'implementazione del runtime della lingua. Il collector per .NET è molto diverso dal collector per Javascript, ad esempio. Gli oggetti nativi creati in entrambi devono rispettare le regole molto rigide del collezionista. Il che a sua volta significa che avrebbero dovuto creare versioni di WinRT specifiche per ogni linguaggio di runtime. Ciò non funzionerà, nemmeno un'azienda grande come Microsoft non può permettersi di creare e supportare una versione specifica di WinRT per ogni lingua. Né è necessario, dato che queste lingue supportano già COM.

Al momento, la migliore associazione per WinRT è C ++ poiché COM funziona in modo più efficiente con la gestione esplicita della memoria. Con ampio aiuto dalle nuove estensioni del compilatore C ++ che lo rendono automatico, molto simile a _com_ptr_t di una volta con sintassi simile a C ++ / CLI per evitarlo. Il legame con le lingue gestite è relativamente semplice poiché il CLR ha già un eccellente supporto per l'interoperabilità COM. WinRT ha anche adottato il formato dei metadati di .NET. Dopo tutto, ad oggi non è stato fatto alcun lavoro sui compilatori gestiti.

EDIT: Larry Osterman, un noto programmatore e blogger Microsoft, ha lasciato un commento piuttosto buono in una risposta ora cancellata. Lo citerò qui per preservarlo:

WinRT non è gestito perché il sistema operativo non è gestito. E progettando WinRT nel modo in cui è stato progettato, ottiene la capacità di essere espresso in molte lingue diverse, non solo in C ++, C # e JS. Ad esempio, ho potuto facilmente vedere una serie di moduli Perl che implementano le API WinRT che funzionano sul desktop. Se lo avessimo implementato in .Net, sarebbe stato estremamente difficile

— Hans Passant
fonte

Non conosco i compilatori, ma sono abbastanza sicuro che la proiezione di WinRT .NET abbia svolto molto lavoro su CLR. Potrebbero aver riutilizzato il codice di interoperabilità COM, ma ci sono anche differenze (ad esempio, IInspectableti permette di fare cose come interrogare un oggetto per il suo tipo di classe attuale o l'elenco di tutte le interfacce supportate, e con i file winmd puoi proiettare i metadati WinRT per tutto ciò in Reflection ). E i file winmd non sono immediatamente utilizzabili come assembly di interoperabilità, CLR deve gestirli in modo speciale.

— Pavel Minaev,

Non sono sicuro, stai ignorando l'elefante. IInspectable è un sostituto di IDispatch bloccato nel 1997. Lavori per Microsoft, sentiti libero di rivelare alcuni dei segreti qui :)

— Hans Passant,

È stato svolto un lavoro in tutte e 3 le lingue per supportare le proiezioni linguistiche.

— Ripristina Monica Larry Osterman il

Direi che in questo momento "il miglior binding per WinRT" è in realtà C #. L'associazione CLR è ottimizzata anche oltre l'interoperabilità COM piuttosto veloce, e i linguaggi .NET nell'anteprima di sviluppo implementano già un eccellente supporto per le onnipresenti funzioni asincrone con "wait". In alcune demo il codice C # ha fatto molto più degli esempi C ++ e ha funzionato più facilmente. Forse in seguito il C ++ otterrà un'estensione dell'helper asincrono, ma in questa versione il C ++ asincrono sembrava terribile. E hai meno probabilità di perdere la memoria a lungo termine dall'immondizia che raccoglie CLR rispetto all'implementazione C ++ problematica del ciclo. C # FTW!

— Govert,

@Hans: la 3a proiezione è il CLR per tutte le lingue CLR (principalmente C # e VB). Inoltre WinJS non è una proiezione, è un insieme di librerie di supporto. La proiezione è direttamente integrata nel motore Chakra JS.

— Ripristina Monica Larry Osterman il

WinRT non è gestito perché è destinato a sostituire Win32, l'API accessibile per sviluppatori di livello più basso per Windows. Un'API non gestita è ancora la più potenzialmente performante che può essere esposta allo sviluppatore e il ragionamento afferma che sarà sempre possibile racchiudervi un'API gestita, che è esattamente ciò che fanno le "proiezioni".

Significa anche che gli sviluppatori C ++ possono usare WinRT senza saltare attraverso i cerchi introdotti da C ++ / CLI (vedi http://www2.research.att.com/~bs/bs_faq.html#CppCLI ) Significa comunque che dovrai comunque devi studiare COM se vuoi usare WinRT.

La vera domanda è "perché è necessario COM? perché Microsoft ha dovuto inventarlo? ' Perché il semplice C ++ senza tutte le funzionalità aggiunte di COM è inadeguato per il vero lavoro OOP e le affermazioni di Stroustrup sul C ++ che ti danno "portabilità" sono molto disingenuose alla luce della realtà lavorativa. Vedi http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/

— Andz
fonte

Link aggiornato per i pensieri di Bjarne su C ++ / CLI: stroustrup.com/bs_faq.html#CppCLI