Pourquoi WinRT n'est pas géré?
Windows 8 présente WinRT, qui est comme .NET mais non géré. Pourquoi est-il non géré? Est-ce un problème de performances? Cela signifie-t-il que la récupération de place ne convient pas aux API de niveau inférieur?
WinRT est un remplacement pour le vieux Winapi basé sur C. Il s'agit d'une API qui doit être utilisable dans de nombreux environnements d'exécution. Il y a 20 ans, une API C était relativement facile à interopérer. Cela a évolué depuis lors, COM est devenu la colle universelle dans la dernière moitié des années 1990. Pratiquement tout runtime de langue couramment utilisé dans Windows prend en charge COM.
Un garbage collector est un détail d'implémentation de l'exécution du langage. Le collecteur pour .NET est très différent du collecteur pour Javascript par exemple. Les objets natifs créés dans l'un ou l'autre doivent respecter les règles très strictes du collecteur. Ce qui signifie à leur tour qu'ils auraient dû créer des versions WinRT spécifiques à chaque langue d'exécution. Cela ne suffira pas, même une entreprise aussi grande que Microsoft ne peut pas se permettre de créer et de prendre en charge une version WinRT spécifique pour chaque liaison de langue. Ce n'est pas non plus nécessaire, étant donné que ces langues prennent déjà en charge COM.
À l'heure actuelle, la meilleure liaison pour WinRT est C++, car COM fonctionne plus efficacement avec une gestion de la mémoire explicite. Avec une grande aide des nouvelles extensions du compilateur C++ qui le rendent automatique, très similaire à _com_ptr_t de l'ancien avec une syntaxe de type C++/CLI pour l'éviter. La liaison aux langages gérés est relativement simple car le CLR dispose déjà d'un excellent support d'interopérabilité COM. WinRT a également adopté le format de métadonnées de .NET. Afaik, aucun travail n'a été effectué sur les compilateurs gérés à ce jour.
EDIT: Larry Osterman, un programmeur et blogueur Microsoft bien connu, a laissé un assez bon commentaire dans une réponse maintenant supprimée. Je vais le citer ici pour le conserver:
WinRT n'est pas géré car le système d'exploitation n'est pas géré. Et en concevant WinRT de la manière dont il a été conçu, il gagne la capacité à s'exprimer dans de nombreux langages différents, pas seulement C++, C # et JS. Par exemple, je pouvais facilement voir un ensemble de modules Perl qui implémentent les API WinRT qui fonctionnent sur le bureau. Si nous l'avions implémenté dans .Net, cela aurait été extrêmement difficile
WinRT n'est pas géré car il est destiné à remplacer Win32 - l'API accessible au développeur de niveau le plus bas pour Windows. Une API non managée est toujours la plus potentiellement performante qui peut être exposée au développeur et le raisonnement veut qu'il sera toujours possible d'envelopper une API gérée par-dessus, ce qui est précisément ce que font les `` projections ''.
Cela signifie également que les développeurs C++ peuvent utiliser WinRT sans passer par les cadres que C++/CLI introduit (voir http://www2.research.att.com/~bs/bs_faq.html#CppCLI ) It signifie cependant que vous devrez toujours étudier COM si vous souhaitez utiliser WinRT.
La vraie question est "pourquoi COM est-il nécessaire? pourquoi Microsoft a-t-il dû l'inventer? Parce que le C++ simple sans toutes les fonctionnalités supplémentaires de COM est inadéquat pour le vrai OOP travail et les affirmations de Stroustrup selon lesquelles le C++ vous donne la "portabilité" sont très très fallacieux à la lumière de la réalité de travail. Voir http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/