Microsoft souhaite transpiler le code C# en code C++

Microsoft souhaite transpiler le code C# en code C++
afin d’exécuter les programmes .Net de manière native sur les plateformes dépourvues du framework .Net

Lorsque vous écrivez un programme qui ne s’exécute pas nativement, vous aurez besoin d’installer des outils pour exécuter ce programme. Cela peut être une machine virtuelle, une chaîne de compilation et bien d’autres encore.

Microsoft qui mise beaucoup sur son langage de développement C# souhaite porter ce langage au-delà des limites qu’on lui connaît actuellement. Lorsque vous développez une application .Net, un des avantages liés à ce langage est qu’il bénéficie d’une prise en charge sur les plateformes Linux, Windows, OS X, Android, iOS. Pour que ces programmes puissent s’exécuter sur ces plateformes, ils s’appuient sur un ensemble d’outils .Net disponibles pour ces plateformes.

Dans les faits, cela signifie que le code ne s’exécute pas nativement directement, mais s’appuie sur la machine virtuelle CLR (Common Language Runtime) du framework .Net afin d’exécuter le code intermédiaire généré.

Cela constitue déjà un grand avantage, mais si l’envie vous prenait d’écrire une application en C# pour une plateforme sur laquelle il n'existe pas d'implémentation .Net, vous serez simplement bien obligé de vous tourner vers d’autres langages ou d’autres solutions.

Microsoft souhaite donc lever cette limite afin d’utiliser son langage C# là où les outils .Net ne sont pas disponibles. Pour cela, la firme a annoncé récemment qu’elle travaille ardemment sur son environnement d’exécution CoreRT afin d’offrir une compilation native à 100 % pour les programmes écrits en C#.

Actuellement, CoreRT intègre en son sein le compilateur à la volée RyuJIT qui permet de compiler le bytecode en code natif spécifique à chaque système d’exploitation (Linux, Windows, OS X). C’est sur ce principe que sont basées les applications universelles Windows.

Pour porter C# encore plus loin, c’est-à-dire dans des environnements non équipés d’outils .Net, Microsoft envisage de transpiler le code .Net en code C++ qui pourrait être compilé par la suite avec un compilateur approprié pour cibler une plateforme quelconque. Comme Microsoft le souligne, « cette stratégie ouvre des portes pour le développement matériel parce que l’on n’aura plus besoin d’attendre qu’un ingénieur Microsoft étende nos compilateurs pour soutenir un nouveau matériel ou un nouveau système d’exploitation afin de permettre aux développeurs .NET de travailler avec votre produit ». Ce projet promet donc de grandes choses une fois sorti du laboratoire.

Toutefois, l’on est encore loin du compte, car C++ n’offre pas de correspondance directe pour les outils .Net. Les ingénieurs Microsoft ainsi que la communauté open source devront trouver le moyen de faire correspondre les fonctionnalités .Net à C++.

De même, plusieurs classes .Net peuvent implémenter la même interface, ce qui peut être déroutant pour le transpileur. À ce niveau-là également, les mainteneurs du projet CoreRT doivent permettre au transpileur d’être assez intelligent pour savoir quelle classe doit être instanciée et passée comme interface. Enfin, une classe .Net peut implémenter des méthodes virtuelles qui appartiennent à une autre classe ou superclasse. Il va falloir également trouver le moyen de conserver ces interactions en C++.

Tout comme CoreRT, plusieurs autres projets dont Nuitka (transpileur Python vers C++) ont vu le jour afin d’offrir aux langages de programmation une passerelle vers C++ pour améliorer les performances et aussi pouvoir porter ces langage vers d’autres plateformes. Mais à l'instar de CoreRT, plusieurs difficultés parsèment le chemin menant à la réussite de ces projets.

Source : Blog Microsoft

Et vous ?

:fleche: Que pensez-vous de ce projet ?

Voir aussi

:fleche: Microsoft dévoile la feuille de route de .NET Core, l'entreprise compte apporter des concepts de programmation fonctionnelle aux langages .NET
:fleche: Microsoft annonce la disponibilité générale de .NET Core 1.0 et ASP.NET Core 1.0 pour Windows, OS X et Linux
:fleche: ASP.NET 5 devient ASP.NET Core 1 et .Net Core 5 est maintenant appelé .NET Core 1.0 pour mieux se démarquer des anciens frameworks

:fleche: La Rubrique Dotnet, Forum Dotnet, Cours et tutoriels Dotnet, FAQ Dotnet

Bonne idée, je suis curieux de voir ce que ça va donner. Je me demande notamment comment il vont gérer certaines features comme la réflexion, les métadonnées (attributs), la génération dynamique de code, le GC...

Citation:

---

Envoyé par tomlev

Bonne idée, je suis curieux de voir ce que ça va donner. Je me demande notamment comment il vont gérer certaines features comme la réflexion, les métadonnées (attributs), la génération dynamique de code, le GC...

---

Facile, en abandonnant le projet parce que c'est infaisable. Ce ne sera pas le premier grand projet à finir à la poubelle.

Citation:

---

Envoyé par 23JFK

Facile, en abandonnant le projet parce que c'est infaisable. Ce ne sera pas le premier grand projet à finir à la poubelle.

---

Avec ce genre de raisonnement on en serait encore à taper sur des silex pour faire du feu... Si tu abandonnes un projet dès que tu rencontres une difficulté, tu vas pas aller bien loin :roll:.

Je veux bien croire qu'ils peuvent se passer d'un GC s'ils font comme Swift (cf: ARC), c'est-à-dire en transpilant les types vers du smart pointer, mais j'ai plus de mal avec tout ce qui concerne l'introspection à moins d'encapsuler chaque type dans une enveloppe généré contenant toutes les informations possibles, et de tuer au passage les performances.

Je ne sais pas si transpiler un langage en particulier vers un autre représente une solution de facilité mais je n'adhère pas. Je pense qu'ils devraient non pas transpiler le code C# directement vers du C++, mais générer un binaire à partir d'un CLI démunie de System.Reflection, je pense que non seulement la compilation s'en trouverait accéléré (plus de parsage de code) et tous les langages tournant actuellement sur la CLR pourraient en bénéficier.

Comme beaucoup, je suis curieux de savoir la solution qui sera retenue pour mettre à disposition les différents mécanismes propre au CLR qui nécessite donc le framework (ramasse-miette, réflexion, attribut de classe et de méthode, etc...).

Par exemple, et comme cela a été annoncé plus haut, l'utilisation de pointeur intelligent permettrait d'avoir une implémentation basique du ramasse-miette. Mais malheureusement insuffisant car cela ne suffirait pas à gérer les données circulaires.

La réflexion est peut-être la partie la plus simple. Ce sont juste des métadonnées à générer auxquelles il faut juste pouvoir accéder lors de l'exécution.
Les attributs relèvent a priori d'un mécanisme similaire à la réflexion (ajout des métadonnées).

Citation:

---

Envoyé par Olivier Famien

De même, plusieurs classes .Net peuvent implémenter la même interface, ce qui peut être déroutant pour le transpileur. À ce niveau-là également, les mainteneurs du projet CoreRT doivent permettre au transpileur d’être assez intelligent pour savoir quelle classe doit être instanciée et passée comme interface.

---

Là, j'avoue ne pas avoir compris du tout ce passage. Un rappel : en C++, il n'y a pas de notion d'interface, uniquement de classe. Pour simuler une interface, il faut passer par une classe totalement abstraite. Le C++ autorisant l'héritage multiple, où se situe le problème ?

Citation:

---

Envoyé par Olivier Famien

Enfin, une classe .Net peut implémenter des méthodes virtuelles qui appartiennent à une autre classe ou superclasse.

---

C'est un peu le principe de l'héritage et du polymorphisme. Encore une fois, où est le problème, dans la mesure où ces deux langages supportent ces notions ?

Citation:

---

Envoyé par Olivier Famien

Il va falloir également trouver le moyen de conserver ces interactions en C++.

---

Ca c'est tout à fait juste ! D'autant plus juste que les interactions vont dépendre d’énormément de paramètres : de l'architecture, de l'OS, du compilateur utilisé, etc...

@dorinf,

Pour les références circulaires il y a weak_ptr.
Une interface n'est ni plus ni moins une classe n'ayant que des méthodes virtuelles pures en C++. Si tu lis les commentaires du lien Microsoft, le problème serait lié à la transpilation des interfaces C# vers du code C++ à cause du comportement différent de la covariance et de contravariance ;)

Citation:

---

Envoyé par Gugelhupf

Pour les références circulaires il y a weak_ptr.

---

Cela ne suffit malheureusement pas. Le seul moyen pour un ramasse-miette de savoir si une référence peut ou non être collectée, c'est de vérifier si elle est accessible. Le nombre de pointeurs référençant cette variable donne une information, mais qui n'est pas suffisante. Une référence non référencée est collectable. Une référence référencée peut l'être... ou pas ! Les pointeurs, aussi intelligents soient ils, ne permettent pas de résoudre cette problématique.

Citation:

---

Envoyé par Gugelhupf

Une interface n'est ni plus ni moins une classe n'ayant que des méthodes virtuelles pures en C++. Si tu lis les commentaires du lien Microsoft, le problème serait lié à la transpilation des interfaces C# vers du code C++ à cause du comportement différent de la covariance et de contravariance ;)

---

Effectivement, je n'ai pas lu le lien. Maintenant, c'est beaucoup plus claire :) Le soucis est donc dû à l'utilisation conjointe de l'héritage et de la généricité.

Je pense que MS devrait déterrer S# et reprendre certains mécanisme de Bartok ils ont utilisés ça pour Singularity

bonjour

La transpiration c'est ce qui est fait déjà dans le C++ Cli, ce qui est une véritable usine gaz ,dont la corvée est laissé au programmeur ...!!!

Citation:

---

Envoyé par MABROUKI

bonjour

La transpiration c'est ce qui est fait déjà dans le C++ Cli, ce qui est une véritable usine gaz ,dont la corvée est laissé au programmeur ...!!!

---

ça doit être pour cela que ça fait suer

Citation:

---

Envoyé par dorinf

Cela ne suffit malheureusement pas. Le seul moyen pour un ramasse-miette de savoir si une référence peut ou non être collectée, c'est de vérifier si elle est accessible. Le nombre de pointeurs référençant cette variable donne une information, mais qui n'est pas suffisante. Une référence non référencée est collectable. Une référence référencée peut l'être... ou pas ! Les pointeurs, aussi intelligents soient ils, ne permettent pas de résoudre cette problématique.

---

En fait si, c'est le mécanisme proposé par C++ pour résoudre le cas des données circulaires (collectables mais référencées).

Citation:

---

Envoyé par ac_wingless

En fait si, c'est le mécanisme proposé par C++ pour résoudre le cas des données circulaires (collectables mais référencées).

---

Si c'était réellement aussi simple, je doute fortement qu'il y aurait autant de travaux sur les ramasses-miettes, qu'ils soient encore améliorés et optimisés après des décennies de recherche, qu'ils catégorisent les objets en fonction de leur durée de vie ou de leur taille alors qu'il "suffit" d'utiliser des weak pointeurs... La libération des ressources serait quasi-instantanée et ne bloquerait donc jamais une application pendant plusieurs centaines de ms, voire plus.

J'ai du mal à comprendre pourquoi M$ veut absolument que le .net se transpose en C++.

L'avantage du .net, c'est la CLR, c'est la (non) gestion de la mémoire, c'est tous les mécanismes d'une machine virtuelle. Le portage sur une autre OS / plateforme ne devrait pas poser de problème, puisque java y arrive ;).

M$ a même développé le Micro-Framework pour de l'embarqué. Y a pas tout le Framework, mais c'est largement suffisant pour ce que c'est faire un micro-contrôleur.

Si c'est le C++ qui est trop complexe, c'est peut être là qu'il faut chercher une alternative, plutôt que de bidouiller un truc sur un coin de bureau :aie:

Je pense que Microsoft l'a déjà fait.

Merci de consulter la video suivante :https://www.youtube.com/watch?v=Z41Z...bQ17FZDaylVROE (précisément à la 39min)

Citation:

---

Envoyé par jpouly

J'ai du mal à comprendre pourquoi M$ veut absolument que le .net se transpose en C++.

---

Parce que c'est peut être plus simple de créer ce transpileur et avoir accès à un très grand nombre de plateformes que de créer une clr pour toutes les plateformes.

Ça peut être pas mal! Il est vrai que mricrosoft devra gérer de nombreux problèmes avant que cela puisse fonctionner , Et encore c'est pas dit que ce projet voit le jour !

tres content d'avoir pris le tournant des le début et faire du web en C++ plus performant et répondant a des norme de sécurité des clients (les miens) ...
d'autant plus que j'avais mis un article sur la libwebsocket en c++ ( WEBSOCKET) et que sur developpez on me l'avait bazardé remis gentiment après discutions ... cet article faisait référence a la validation du temps réel synchrone validé par l'ensemble des acteurs Informatique janvier 2016 ( IBM MOZILLA MICROSOFT APPLE ......) et très gros comptes ... bref les programmes que ce soit avec browser ou console ou interactif peuvent désormais travailler et faire du temps reel ( tenue d'enregistrement commit .... ) sans que la bande passante s'affole ni que votre compteur geger(CPU) pete les plombs en C++.
je vous parle du C++ mais ils y a [php mais mais.... java oui en c# avec une programme fait en GO vous le trouverer sur wikipedia dans la rubrique WEBSOCKET ] sur lesquels les implémentations on été porté c'est vrais peu de doc car l'ensemble des lib dès la signature et ratification sont passé à la mise en conformité (la doc vas arrivé), d'ailleurs je signal au passage que Microsoft a annoncé qu'il n'implémenterait pas en dessous d'explorer 10 voir la même chose pour safari le dernier en date de cette année et vous avez plus de chance pour firefox pour ma part sur Linux j'ai de la chance d'avoir pu très tôt bénéficié de cette lib et fait des tests j'ai d’ailleurs mis sur gitub(ou sur mon site) un test qui permet de comprendre les mécanismes de connexion avec un pti serveur (23ko hors métier) lancer en console pour suivre les ébats de vos élucubrations de votre page html button connexion ect... avec des envoies données et réception de donnée pour bien comprendre le flux.

je suis très content de cette décision que Microsoft fasse cela . d'autant que mes amis qui sont dans le monde bancaire (je ni suis pas) me disait qu'ils étaient obligés de reconsidérer les choses et ce tourner soit vers d'autre platforme (AS400 .. ça ne fait pas que de l'écran vert ... le mode synchrone est natif ) et d'autre langage car la vitesse était le principal problème et la prise en compte mode synchrone, maintenant que le mode synchrone est résolu
je vous laissent a vos clavier .... moi j'y retourne ...
@bientôt

ça veut dire quoi to transpile en anglais ??? Et ça se traduit par transpiler ??? Je dois commencer à me faire vieux (oui j'ai vérifié Google traduction traduit PARFOIS transpile par transpiler mais ça ne lui donne pas forcément raison (heureusement).
Vérification faite Transpile est une abbréviation pour transcompile traduire d'un langage source à un autre.
Là je comprend et je reste surpris par le transpiler.

N'est-ce pas déjà ce que Unity fait avec son compilateur IL2CPP? de plus Unity fait partie de la .Net Foundation :roll:
Je ne serai pas surpris que ce soit la même technologie

Citation:

---

Envoyé par tomlev

Avec ce genre de raisonnement on en serait encore à taper sur des silex pour faire du feu... Si tu abandonnes un projet dès que tu rencontres une difficulté, tu vas pas aller bien loin :roll:.

---

sans compter que si tu frappes deux silex l'un contre l'autre tu n'auras jamais de feu ^^
(il faut silex + pierre contenant du fer)