Dès qu'on souhaite appeler des bibliothèques natives, on se heurte à des problèmes de portabilités (et ceci, même si la dite bibliothèque est portable).
Je ne vois absolument pas en quoi t'appuyer sur Qt va t'aider à résoudre ce problème.
C# possède au contraire un des rares systèmes pour faire des appels à des bibliothèques natives de façon portable (sans glue façon java) grâce aux PInvoke : tu n'as même pas besoin de recompiler ton code managé qui appelle ta lib native. Evidemment ca suppose que ta lib soit effectivement portable à travers une interface C indépendante de la plateforme (ex : OpenGL).
langage compilé ou vm
C# est un langage compilé et nécessite obligatoirement une VM pour fonctionner : introspection, gestion de la mémoire, gestion des exceptions, etc.
Il peut même être précompilé en code natif avant exécution : les services de la VM sont toujours présents à l'exécution.
En fait ton problème, c'est pas la portabilité, ce sont des problèmes d'incompatibilité entre 2 implémentations. Dans ton exemple un problème de compatibilité entre Apache/Mono et IIS/.NET.
Créer une nouvelle plateforme (ce que tu proposes puisque ca ne sera pas 100% du C# ni 100% du Qt) est une fausse solution : si demain quelqu'un fork et que tu te retrouves avec 2 implémentations t'auras les mêmes soucis.
# mouaich
Posté par TImaniac (site web personnel) . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 5.
Je ne vois absolument pas en quoi t'appuyer sur Qt va t'aider à résoudre ce problème.
C# possède au contraire un des rares systèmes pour faire des appels à des bibliothèques natives de façon portable (sans glue façon java) grâce aux PInvoke : tu n'as même pas besoin de recompiler ton code managé qui appelle ta lib native. Evidemment ca suppose que ta lib soit effectivement portable à travers une interface C indépendante de la plateforme (ex : OpenGL).
C# est un langage compilé et nécessite obligatoirement une VM pour fonctionner : introspection, gestion de la mémoire, gestion des exceptions, etc.
Il peut même être précompilé en code natif avant exécution : les services de la VM sont toujours présents à l'exécution.
En fait ton problème, c'est pas la portabilité, ce sont des problèmes d'incompatibilité entre 2 implémentations. Dans ton exemple un problème de compatibilité entre Apache/Mono et IIS/.NET.
Créer une nouvelle plateforme (ce que tu proposes puisque ca ne sera pas 100% du C# ni 100% du Qt) est une fausse solution : si demain quelqu'un fork et que tu te retrouves avec 2 implémentations t'auras les mêmes soucis.