Microsoft souhaite transpiler le code C# en code C++
Afin d'exécuter les programmes .Net nativement sur les plateformes dépourvues du framework .Net

Le , par Olivier Famien

25PARTAGES

7  0 
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 ?

Que pensez-vous de ce projet ;?

Voir aussi

Microsoft dévoile la feuille de route de .NET Core, l'entreprise compte apporter des concepts de programmation fonctionnelle aux langages .NET
Microsoft annonce la disponibilité générale de .NET Core 1.0 et ASP.NET Core 1.0 pour Windows, OS X et Linux
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

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 22/10/2016 à 0:12
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...
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 22/10/2016 à 1:24
Citation Envoyé par tomlev Voir le message
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.
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 22/10/2016 à 1:30
Citation Envoyé par 23JFK Voir le message
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 .
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 22/10/2016 à 8:03
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.
Avatar de François DORIN
Rédacteur https://www.developpez.com
Le 22/10/2016 à 9:34
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 Voir le message

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 Voir le message

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 Voir le message

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...
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 22/10/2016 à 11:48
@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
Avatar de François DORIN
Rédacteur https://www.developpez.com
Le 22/10/2016 à 13:00
Citation Envoyé par Gugelhupf Voir le message
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 Voir le message

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é.
Avatar de redcurve
Membre confirmé https://www.developpez.com
Le 22/10/2016 à 15:33
Je pense que MS devrait déterrer S# et reprendre certains mécanisme de Bartok ils ont utilisés ça pour Singularity
Avatar de MABROUKI
Membre expert https://www.developpez.com
Le 22/10/2016 à 16:36
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 ...!!!
Avatar de zobal
Membre confirmé https://www.developpez.com
Le 22/10/2016 à 17:27
Citation Envoyé par MABROUKI Voir le message
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
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web