Discussion :

[Orwell]

Salut,

Bon ma question risque de paraître stupide, mais j'ai beau consulter les facs et les tutos que je trouve sur .NET et le C++/CLI, et je n'arrive pas à obtenir une réponse claire à mon problème:

Peut-on utiliser (toutes) les classes de .NET (WinForms, Collections, etc etc) dans du code C++ non managé?

Je sais qu'on n'a bien sur pas accès au CLR, mais cela inclut-il toutes ces classes également?

Mon problème est le suivant: j'ai une petite application (avec GUI) qui tourne en C#, mais qui malheureusement se traine un peu (beaucoup). Je voudrais passer en C++ pour obtenir du code natif qui s'exécuterait plus vite, mais je voudrais aussi continuer à profiter de toutes les classes confortables de l'interface .NET que j'utilise en C# (ça faciliterait la transition aussi).
Donc, est-ce que c'est possible ou bien dois-je me tourner vers des solutions alternatives (MFC, Qt)?

Merci à celui/ceux qui voudra/ont bien éclairer ma lanterne sur ce point

[Mose]

Peut-on utiliser (toutes) les classes de .NET (WinForms, Collections, etc etc) dans du code C++ non managé?

Non, aucune. C'est un peu comme si tu demandais "Peut-on utiliser les librairies Java directement dans une appli en C++". La réponse est : définitivement non.

Mon problème est le suivant: j'ai une petite application (avec GUI) qui tourne en C#, mais qui malheureusement se traine un peu (beaucoup). Je voudrais passer en C++ pour obtenir du code natif qui s'exécuterait plus vite, mais je voudrais aussi continuer à profiter de toutes les classes confortables de l'interface .NET que j'utilise en C# (ça faciliterait la transition aussi).
Donc, est-ce que c'est possible ou bien dois-je me tourner vers des solutions alternatives (MFC, Qt)?

J'ai entendu parler d'un convertisseur (un truc qui réécrit), mais je doute qu'il soit complet. C'est un ancien thread de ce forum. Bonnes recherches.

[Orwell]

C'est bien ce qu'il me semblait...
Merci pour la confirmation

[Monkeyget]

Tu pourrais faire ton applis en c#, voir quels sont les parties de l'appliation qui sont trop lentes (profiling) et convertir uniquements ces bouts de code en natif pour obtenir des performances correctes.

[dev01]

Salut .

ce genre de problème de lenteur arrive à 95% à cause de la façon de programmer plutot qu'a cause de l'architecture ...

Donc premierement :
-As tu auditer ton code avec des outils comme NCover afin de voir les goulets d'étranglement ?

-Si oui est que tu es sur de ne rien pouvoir y faire as tu essayer de générer une image native de ton programme grâce à ngen (fourni avec le SDK de .NET ) ?

[nico-pyright(c)]

c'est à ca que sert le c++/cli
pouvoir mixer aisément code managé et non managé, pour mieux comprendre, je te propose cet article

[dev01]

c'est à ca que sert le c++/cli
pouvoir mixer aisément code managé et non managé, pour mieux comprendre, je te propose cet article

ouais mais tu utilises quand les classes de base du fx dans du code managé non ?
Et puis lui montre pas de bétises, il code en C# c'est bien mieux

[nico-pyright(c)]

c'est sur que le gain à faire tout en c# ou tout en C++/CLI est completement négigeable (meme si la syntaxe est mieux en C++/CLI )

Par contre, il est possible de generer du code natif en c++/cli, grace aux pragmas cités dans l'article. Ce qui peut accelerer la vitesse, à condition que ce soit bien organisé. En effet, les passages du monde managé au monde non managé coutent cher, donc il faut gerer cela correctement.

Ce qui est certain, c'est qu'on ne peut pas utiliser des classes du framework.Net dans la partie de code "native", c'est évident, mais l'utilisation du c++/cli facilite la communication entre les deux mondes et permet de mixer efficacement code natif et code managé

Mais tout ceci, nécessite comme tu le dis, de penser de manière adéquate la solution, et de pas faire n'importe quoi

Je pense globalement que ce n'est pas ici que tu gagneras du temps, à moins que ce que tu veuilles faire en vaille vraiment la peine et soit énormément consommateur de ressources

[Orwell]

J'avais déjà lu l'article de nico avant de poster mon message, mais ça ne m'éclaire malheureusement pas plus...

Ce qui est étonnant c'est que le passage du C# au C++/CLI m'a été suggéré par le prof qui supervise mon boulot, et qui donne accessoirement aussi des cours sur .NET
De plus, en consultant le gros bouquin que j'ai sur .NET ("C# et .NET version 2", G Leblanc, Eyrolles), je constate qu'en fait avec .NET tout s'exécute en natif, puisque le JITC se charge de compiler le MSIL au fur et à mesure de l'execution. On a donc pourtant bien une utilisation du framework .NET à partir de code "natif" (dans le sens où il ne s'exécute pas sur une VM comme Java). J'ai beau relire l'article de nico, je n'arrive pas à voir exactement la différence entre "managé ou non" et "natif ou non". Il semble qu'il y ait une grosse confusion entre ces deux concepts.
Le code managé une fois compilé est sans doute simplement moins rapide à cause du CLR, mais l'affirmation

Ce qui est certain, c'est qu'on ne peut pas utiliser des classes du framework.Net dans la partie de code "native", c'est évident,

ne me parait finalement pas si évidente que ça

[nico-pyright(c)]

j'vais essayer de résumer l'article

si tu compiles en mode /clr (et autres), tu crées du MSIL qui sera interprété par le VES (Virtual Execution System), donc rien n'est natif. Cependant, lors de l'écriture du code, tu peux mixer du code managé et du code non managé. Mais dans tous les cas, le résultat sera du MSIL.

Si tu compiles en mode natif (pas de /clr), ton application sera native et c'est tout. Tu ne pourras pas utiliser le framework.Net.

Il y a une troisième solution : c'est de compiler en /clr et d'encadrer certaines fonctions par les pragma #managed et #unmanaged. Tout sera en MSIL sauf ces parties de codes comprises dans les pragmas, qui seront du natif pur. La seule recommandation est que de passer du MSIL au natif dans le meme programme prend du temps, donc il faut l'utiliser judicieusement.

Natif = pas de framework.net

[Orwell]

C'est pourtant en totale contradiction avec mon bouquin...

Selon le livre cité plus haut (page 7),

Les compilateurs créant des programmes pour .NET doivent générer le code intermédiaire, appelé MSIL. Il s'agit d'un code intermédiaire entre le code source (par exemple du code C# ou Visual Basic) et le code natif directement exécutable par le microprocesseur. Ce code intermédiaire est donc indépendant du code de bas niveau qu'est le langage machine, mais il est capable de manipuler ces constructions de haut niveau que sont les objets.

Jusque là pas de soucis.

Paragraphe suivant:

Au moment d'exécuter un programme, ce code intermédiaire est pris en charge par .NET qui le fait exécuter, fonction après fonction, par un JIT compiler. .NET procède par compilation et non par interprétation, toutefois il s'agit d'une compilation (de code MSIl en code natif) en cours d'exécution de programme. Au moment de commencer l'exécution d'une fonction, mais lors du premier appel seulement, .NET appelle le JIT. Le JIT, qui connait alors l'environnement d'exécution, et notamment le type de microprocesseur, compile le code intermédiaire de la fonction en code natif, en fonction du microprocesseur réellement utilisé (ce qui permet une optimisation. Du code natif est alors exécuté. (...) Très rapidement, on n'exécute plus que du code natif optimisé pour le microprocesseur de l'utilisateur.

A comparer avec

si tu compiles en mode /clr (et autres), tu crées du MSIL qui sera interprété par le VES (Virtual Execution System), donc rien n'est natif. Cependant, lors de l'écriture du code, tu peux mixer du code managé et du code non managé. Mais dans tous les cas, le résultat sera du MSIL.

Et c'est là que le bât blesse... Alors quid?

Selon la manière dont moi je vois les choses, l'activation du CLR permet de spécifier si on souhaite obtenir du code managé ou non (d'ou l'existence des pragma pour désactiver le CLR sur certaines parties du code). Ca n'a rien à voir avec le fait que le code executé soit du MSIL ou du code natif.

NB: je m'excuse auprès de l'auteur d'avoir honteusement pompé ses phrases, mais je pense que ça mérite un approfondissement.

[dev01]

Salut .

Effectivement si tu regarde comment fonctionne le framework, tu te rend compte qu'un programme au cours de son utilisation est peu à peu compiler en code natif. Cela étant dit il ne faut pas confondre méthode de fonctionne et méthode de programmation.

En effet dans le cas du FX c'est du code qui fini par etre exécuté (je passe les détails).

Mais RIEN ne te permet à toi programmeur d'aller directement taper dans le code natifs des bibliothèques de classe. De plus même si on parle de code natif, il y a quand une vérification de sécurité faite par l'environnement d'exécution.

En résumé : tu codes en C#/C++.Cli puis le FX se charge de mettre en code natif au moment de l'éxécution et après vérification de sécurité ..

Elle est pas belle la vie ?

NB: je m'excuse auprès de l'auteur d'avoir honteusement pompé ses phrases, mais je pense que ça mérite un approfondissement.

dis-on que dans ce cas on cite le nom de l'auteur ...

[Orwell]

De plus même si on parle de code natif, il y a quand une vérification de sécurité faite par l'environnement d'exécution.

Evidemment, puisque ça reste du code managé.

En résumé : tu codes en C#/C++.Cli puis le FX se charge de mettre en code natif au moment de l'éxécution et après vérification de sécurité ..
Elle est pas belle la vie ?

Ca ne répond toujours pas à ma question de départ qui est: a-t-on accès aux classes du framework en mode non managé? Vraisemblablement non, mais on n'est pas vraiment plus avancé.

En tout cas si l'auteur du bouquin (dont j'ai cité le nom qq posts plus haut: Gerard Leblanc) ne se trompe pas, nico peut revoir tous ses articles, vu les amalgames natif/unmanaged