Programmation en C++/CLI ?

Je vous avais déjà contacté il y a plus de 3 mois sur les Winforms et le c++/CLI et entre temps je me suis pas mal documenté sur le sujet (surtout à l'aide de vos FAQ et qques ouvrages que j'ai potassé).
Je suis un "bleu" en Visual C++. Mais j'ai déjà construit 3 programmes en DELPHI, qui fonctionnent bien.
Ce sont des programmes "scientifiques" possédant comme dans tous ces types de programmes :
- une fenêtre pour l'entrée des données (et leurs modif si nécessaires) soit un "préprocesseur"
- Le Kernel, dans lequel le calcul s'effectue (calculs matriciels, et de résolutions d'équations du mouvement d'ensemble de points....)
- une fenêtre pour la sortie des résultats (et leurs impressions et graphes).
J'ai déjà programmé la fenêtre d'entrées (préprocesseur) (en C++/CLI) et ça marche pas mal. Je pense que pour les sorties je pourrais rester en C++/CLI pour les graphiques.
Maintenant, pour le KERNEL, j'ai un problème de temps d'execution; j'ai quelques questions à vous poser sur ces orientations.
1 - De ce que j'ai lu, si j'utilise le garbage collector les calculs seront moins rapides qu'avec le heap. Si oui, puis-je rester en C++/CLI et utiliser le c natif et des pointeurs (new, delete) du heap ou dois-je entourer mes parties calcul avec des #pragma unmanaged et #pragma managed. En gros, est-ce que le compilateur saura faire la part des choses entre les 2 "langages".
Pouvez-vous me donner un exemple très simple me montrant l'incrustation d'un code en c natif dans du c++/cli, ou est-ce impossible ?
2 - Quelle est la différence de temps d'execution entre 2 calculs matriciels dans les 2 langages en utilisant des pointeurs.
Si on ne peut pas mélanger les 2 "langages", je peux toujours créer 3 programmes que je lance successivement.

Pouvez-vous m'éclairer sur ce point, SVP.
J'espère que ma demande est claire.

Merci d'avance
Alfred

Tu peux rester en C++/CLI et utiliser des tableaux non-managés.
Simplement:

• Les tableaux non-managés doivent être des tableaux d'un type non-managé ou primitif (genre, tableau de int)
• Tu les alloues avec new au lieu de gcnew (puisqu'ils ne sont pas managés)

Par contre, j'ignore s'il y a des contraintes sur l'interface (genre, ne pas mélanger les deux types dans une liste de paramètres ou des choses comme ça).

s'il y a une contrainte de rapidité d'execution, il peut etre interessant de forcer la génération de code natif et non pas de générer du msil.

je t'encourage à consulter cet article

D'accord, j'ai bien compris.
Si on crée un pointeur de tableau avec new, il sera dans le heap et sera utilisé comme un pointeur normal. Et tout ceci sera dans mon code en c++/cli.
J'ai appris que le compilateur crée du MSIL et non du code objet c++ natif.
Et donc saura-t-il faire la différence et au moment où il trouvera les instructions en natif (non managé) les compilera-t-il dans ce code ?
Pour forcer le compilateur à créer du code natif faut-il donc incruster le kernel (code de calcul à optimiser en temps) entre des directives # pragma unmanaged et # pragma managed ?
Alors si on ne force pas le compilateur à créer du code natif, il créera du MSIL !!!!
Tout cela s'embrouille dans ma tête.
Comment cela se passe-t-il dans la réalité ?

Pour ma part je voudrais rester en c++/cli pour l'utilisation des winforms qui me rappellent ce que j'avais avec les rad de delphi et la gestion des contrôles.

Je vous remercie, déjà pour vos réponses éclair
et attend la ou les réponses à ces nouvelles questions.

Alfred

Si tu utilises simplement new, il me semble que le code sera en MSIL mais l'objet sera dans le tas natif, et tu auras un pointeur natif.

Si tu utilises #pragma unmanaged, je crois que le code sera 100% natif et ne pourra utiliser QUE les objets natifs.

tu peux continuer à utiliser le c++/cli pour bénéficier des winforms par exemple.
Si tu as vraiment besoin que le code soit généré en natif, il faut l'entourer des pragma déjà cités.

Si tu fais cela, toutes les parties hors pragma seront compilées en MSIL, et les parties dans les pragmas seront en code natif.
Attention, les aller-retours entre le msil et le code natif sont couteux en performances, donc il va falloir organiser ton code de manière judicieuse, sinon, cela ne vaudra pas le coup, et il sera plus interessant au final de rester en msil uniquement.

Si tu crées un pointeur avec new, cela voudra simplement dire qu'il ne sera pas geré par le garbage collector, et donc sera alloué sur le heap crt, comme avant

est-ce plus clair ? ;)

OK, et merci vraiment.
Dans mon programme il n'y a que soubroutine qui est gourmande en temps (résolution de 100 à 200 equa diff du 1er ordre par un equivalent à RUNGE KUTTA, pas de temps 0.1ms pour un tps total de 50s).
Dernier point:
Tout le programme sera en managé sauf cette soubroutine. Alors cette soubroutine pourra-t-elle utiliser des tableaux non managés (crées avec new dans le heap) et dans la partie managée ?
Et ensuite, la partie managée pourra-t-elle ré-utiliser ces mêmes tableaux pour fournir les résultats ? (surement que la réponse est oui pour cette dernière question).
Les tableaux garderont-ils leurs mêmes adresses de pointeurs pendant ces passages ?
De plus, quelle, à votre avis, la différence en temps de calcul entre un code écrit en MSIL et un en code machine (en %) ?

Merci beaucoup pour votre patience; j'apprécie vraiment votre gentillesse...

Alfred

oui, on peut faire passer des paramètres entre les deux mondes, ils garderont leurs adresses natives dans le monde managé, dans la mesure où ils ne seront pas gérés par le GC.

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#pragma unmanaged   char * alloueUnChar(int size) { return new char[size]; } #pragma managed   NameSpace Test { ... private: System::Void Form1_Load(System::Object^ sender, System::EventArgs^ e) { char *c = alloueUnChar(100); c[0] = 'a'; c[1] = 'b'; c[2] = '\0'; } ... }

---

tu constates avec le debugger que ce sont les memes adresses.

Au niveau du gain, cela dépend beaucoup de ce que tu fais et des méthodes utilisées. Je ne saurais pas le quantifier, mais il peut arriver que le compilateur ne sache pas convertir des appels natifs en MSIL et qu'il utilise directement du code natif. Dans ce cas le gain est nul.

Mais je t'encourage à tester les deux méthodes pour voir si dans ton cas, cela vaut le coup.

Rappel : essaie de limiter le nombre de passage de managé à non-managé.

Merci encore et toujours, vous êtes vraiment sympas Mrs NICO.... et Medinoc.
Je crois que j'ai compris.
Je vais tester une fois en encadrant ma fonction avec les #prag.... et une fois sans.
Je verrai bien la diff de temps.

Bien cordialement...

Alfred