Ce qui serait bien, c'est que ce soit comme pour Ada. Pour qu'un compilateur puisse dire qu'il compile de l'Ada, il a tout une batterie de tests à passer.
Le problème ce n'est pas le langage : il y a une batterie de tests également pour C#. Le problème c'est les bibliothèques. Même avec toute les batteries de tests du monde, vu la taille et le nombre d'API, on ne peut passer à côté d'incompatibilités.
Il me semble que le projet Mono permette de compiler en code natif et de s'abstraire complètement de la VM. C'est d'ailleurs ainsi qu'ils peuvent compiler une application pour iPhone écrite en C# et la publier, puisque Apple interdit les VM.
Une VM est... virtuelle. Elle n'existe pas. Ce qui compte, c'est le comportement à l'exécution. Et là il existent pleins de techniques pour "simuler" le comportement de la VM : en général c'est un mix d'interprétation, de compilations et de bibliothèques de services (GC & co). Certaines VM se prêtent bien à des techniques de compilation à la volée, d'autres sont fortement limitées à l'interprétation.
La VM .NET sur laquelle s'appui C# a été conçu pour que techniquement on puisse compiler en code natif l'exécutable avant exécution, histoire de gagner du temps au démarrage (effet de bord : passer outre les restrictions Apple).
Le reste des services (GC, sécurité, introspection, etc.) est fournis par des bibliothèques qui sont chargées en même temps que le programme, comme c'est d'ailleurs le cas pour le C++ qui nécessite aussi une sorte de "runtime" pour certaines fonctionnalités (exceptions par exemple).
Donc oui, Mono fait de la compilation en code natif sur iPhone, .NET le fait aussi sous Windows et Mono sait aussi le faire sous Linux : c'est de la compilation Ahead-Of-Time (AOT).
Même dans le mode plus "classique" façon Java (Just-In-Time (JIT)), c'est le même processus qui se passe : compilation en code natif. La seule différence, c'est que dans un cas c'est fait avant l'exécution et l'autre pendant.
Qui génère des problèmes de portabilités. CQFD.
Super, et avec ta solution, je vais appeler une bibliothèque native de IIS, tu vas pas avoir le même problème pour porter ton appli sur Apache ?
Et c'est pourquoi je voudrais proposer une implémentation portable, qui ne nécessiterait pas une autre implémentation pour tenter d'assurer la portabilité
Si Mono existe, c'est aussi pour avoir une alternative sous licence "libre" : donc Mono se fait chier à recoder toutes les libs qui sont non-libres, même si elles sont techniquement portables.
En fait pour résoudre ton problème, t'as qu'à simplement ignorer l'implémentation de Microsoft : voilà, t'as Mono, c'est portable.
C'est vrai. Mais le fork est intrinsèquement lié au libre :)
Fork ou implémentation alternative, et t'auras exactement le même soucis que MS.NET/Mono.
C#/.NET est techniquement une plateforme portable. Les incompatibilités viennent de l'existance de plusieurs implémentations et de choix politiques/économiques de licences de diffusion. Tu résoudras pas ce soucis par une solution technique.
[^] # Re: mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 7.
Le problème ce n'est pas le langage : il y a une batterie de tests également pour C#. Le problème c'est les bibliothèques. Même avec toute les batteries de tests du monde, vu la taille et le nombre d'API, on ne peut passer à côté d'incompatibilités.
Une VM est... virtuelle. Elle n'existe pas. Ce qui compte, c'est le comportement à l'exécution. Et là il existent pleins de techniques pour "simuler" le comportement de la VM : en général c'est un mix d'interprétation, de compilations et de bibliothèques de services (GC & co). Certaines VM se prêtent bien à des techniques de compilation à la volée, d'autres sont fortement limitées à l'interprétation.
La VM .NET sur laquelle s'appui C# a été conçu pour que techniquement on puisse compiler en code natif l'exécutable avant exécution, histoire de gagner du temps au démarrage (effet de bord : passer outre les restrictions Apple).
Le reste des services (GC, sécurité, introspection, etc.) est fournis par des bibliothèques qui sont chargées en même temps que le programme, comme c'est d'ailleurs le cas pour le C++ qui nécessite aussi une sorte de "runtime" pour certaines fonctionnalités (exceptions par exemple).
Donc oui, Mono fait de la compilation en code natif sur iPhone, .NET le fait aussi sous Windows et Mono sait aussi le faire sous Linux : c'est de la compilation Ahead-Of-Time (AOT).
Même dans le mode plus "classique" façon Java (Just-In-Time (JIT)), c'est le même processus qui se passe : compilation en code natif. La seule différence, c'est que dans un cas c'est fait avant l'exécution et l'autre pendant.
Super, et avec ta solution, je vais appeler une bibliothèque native de IIS, tu vas pas avoir le même problème pour porter ton appli sur Apache ?
Si Mono existe, c'est aussi pour avoir une alternative sous licence "libre" : donc Mono se fait chier à recoder toutes les libs qui sont non-libres, même si elles sont techniquement portables.
En fait pour résoudre ton problème, t'as qu'à simplement ignorer l'implémentation de Microsoft : voilà, t'as Mono, c'est portable.
Fork ou implémentation alternative, et t'auras exactement le même soucis que MS.NET/Mono.
C#/.NET est techniquement une plateforme portable. Les incompatibilités viennent de l'existance de plusieurs implémentations et de choix politiques/économiques de licences de diffusion. Tu résoudras pas ce soucis par une solution technique.