Discussion :

[vassilux]

Salut à tous,
Est-ce que quelqu'un a eu l'experience dans un projet industriel avec C++/CLI ?

@+

[nico-pyright(c)]

tu veux qu'on te raconte quoi ?

[vassilux]

Oui , c 'est vrai la question peut être pas trop claire, dsl
L'idée c'est de savoir s'il y a des projets réels, donc j'ai voulu dire industriel, dans C++/CLI et le retour sur l'experience.
La question était abordée dans ma boite suite à la discution d'utilisation de .Net et la migration vers C#.
Voila

[nico-pyright(c)]

ce que je peux te dire, c'est que je pense que le C++/CLI prend toute sa valeur et toute sa puissance dans la migration d'un projet existant en C++.

L'interet est sa capacité à mixer du code natif (Win32, MFC, etc ...) avec le framework .Net ; ce qui fait que l'on peut migrer plus aisément un programme existant et l'agrémenter de fonctionnalités inhérentes au framework.Net.

Réécrire son logiciel existant originellement écrit en C++ en C# est à mon avis contre productif.

Cependant, lorsqu'il s'agit de débuter un nouveau projet, il est à mon avis aussi adapté de le faire en C++/CLI ou en C#, tout dépend du niveau de programmation dans ces domaines

[Gabrielly]

Bonjour

La question était abordée dans ma boite suite à la discution d'utilisation de .Net et la migration vers C#.
Voila

Et quelle a été la conclusion?

[vassilux]

En deux mots , on a des projets avec WTL et MFC pour les PCs et des Pocket PC.
Donc une partie d'equipe et du management trouve que ce genre de bibliotheque est très complexe, à voir la définition de la complexité , et donc il faut passer plus de temps et d'avoir l'equipe plus qualifiée et le point plus important c'est l'utilisation de .Net.
Mon opinion à moi ou ma conclusion , je me sens bien avec MCF et WTL et s'il faut avec .Net et je suis content de cette possibilité de pouvoir mixer entre native et managé.
La conclusion de management n'est pas trop claire, mais c'est la vie et en vie avec.
J'ai possé cette question pour avoir un peu plus d'info sur les evolutions dans les entreprises sur ce point.
Voila
PS : Je m'exuse pour mon français

[nico-pyright(c)]

a mon avis c'est financierement que cela se joue à ce niveau

- soit on migre en douceur en faisant en sorte que ca compile en mixant managé et non managé, puis on change petit à petit les choses "complexes". Ceci à l'interet de pouvoir faire en sorte que l'appli continue à marcher le temps de la migration

- soit on arrete tout et on redeveloppe tout. Le probleme est que l'appli est en chantier pendant le temps de la migration. Donc à savoir si les ressources sont nécessaires pour éviter que cela bloque l'activité