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