Discussion :

[subzero01]

bonjour
je développe en utilisant le .net framework, mais pendant toute la période depuis que j'ai connu mfc j'essaye de me familiariser avec, et d'en faire ma premiere méthode de programmation, mais vu le developpement et les facilités qu'offre le .net, je ne trouve pas assez de raisons pour revenir à mfc
j'aimerai bien connaitre le maximum des avantages de programmation en mfc, parceque je veux bien m'y attacher mais je ne trouve pas une bonne raison pour le faire.

[nico-pyright(c)]

tout dépend du type de projet que tu veux réaliser

l'architecture Document/Vue des MFC est très complete
le framework.net a des avantages qui rend son utilisation très pratique.
Si ton appli doit etre proche du système, il faut privilégier le natif.

Bref, avant toute chose, la bonne question à ce poser est : qu'est-ce que je veux faire ?
et en fonction de ca, une plateforme sera plus adaptée qu'une autre

[subzero01]

vous avez raison
mais des fois on trouve que notre application est aussi faisable dans les mfc que dans le .net, mais vue la complexité des fonctions des mfc, je ne choisis pas cette platform meme si j'aime bien m'adapter a choisir mfc quand le choix ne dépend pas de ce que je veux faire.
EDIT: une simple application réalisée avec une seule form ou deux par exemple, si elle est réalisée en .net, toute la platform .net (de la meme version) doit etre installée sur la machine sur laquelle l'application va tourner ! par contre, si je choisis les mfc, et j'intègre ses librairies dans mon appli, ca peut faciliter les taches... bon, mais faut pas négliger la facilité qu'offre le .net par rapport a la complexité des mfc.

[nico-pyright(c)]

je suis d'accord
pour des applis simple, je vais dix fois plus vite avec .net

[farscape]

je suis d'accord
pour des applis simple, je vais dix fois plus vite avec .net

ah nan pas de publicité subliminale faisant penser a un produit concurrent

[kacedda]

Bonjour a tous,

l'architecture Document/Vue des MFC est très complete

Juste en passant, la j'avoue que je vois pas trop, je connait pas bien le .net, mais apparemment la gestion document/vue est assez fourni aussi. Car il semble que ce soit un des arguments de la plupart des MFC_user. Mais concretement je vois pas de grosses difference, ni petites d'ailleurs...

[nico-pyright(c)]

en .net, il existe des archis open source pour faire comme les MFC, mais rien dans le framework.net, qui comme son nom l'indique n'est "qu'un" framework

Tu voulais peut etre parler de la prorpriété MDI d'une form ?

[kacedda]

Tu voulais peut etre parler de la propriété MDI d'une form ?

Exactement! c'est à ceci que je pensais, personnellement je n'ai jamais developpe en .net, et un ami a fait un soft .net MDI, du coup je me demandai si c'etait vraiment complique de mettre en place le modele document/vue. Auquel cas plus ca va, moins ca va pour les MFC.

[farscape]

Mettre en balance .net et MFC ne résume pas a c’est mieux d’un coté moins bien de l’autre.
Programmer en MFC c’est déjà programmer en C++
Certains programmeurs te diront que c’est déjà un argument.

Il est clair que coté .net l’environnement est plus simple à mettre en œuvre que les MFC. (sauf si tu disposes comme moi d'un ensemble d'outils maison)

Mais que peux-tu me dire d’une application .Net travaillant en MDI avec une possibilité d’une centaine de fenêtres différentes ?
Et je parle a tout les niveaux : organisation du code, maintenance, installation en clientèle etc..
En MFC cela fonctionne j’ai quelques programmes comme cela, et je ne pense pas me tromper en disant que le coté natif des MFC va plus vite qu’un programme .net
C’est pour moi un argument majeur, même si pour certains petits développement rapides je regarde du coté de .net.

On peut continuer comme ça longtemps d’un coté comme de l’autre à trouver des avantages et des inconvénients.

Alors je dis ça dépend de ton expérience, du sujet, des contraintes, de ton passif de lignes de codes à maintenir etc..

De plus pour infos ou rappel MS vient de donner un coup de pouce aux MFC avec la bibliothèque bcgsoft qui vient d’être intégrer à Visual 2008.
Je ne pense pas que ça soit un hasard, cela veut bien dire qu’il y a un intérêt à avoir une plateforme de développement native win32 en parallèle de la plateforme .net.

[PetitPapaNoël]

Je suis d'accord avec Farscape.

Moi qui ai eu l'occasion de travailler sur .Net et sur C++/MFC, je peux dire que la programmation sur .Net est plus intuitive et plus rapide que sur C++/MFC.

Par contre, la gestion de la mémoire est opaque sur .Net alors qu'on fait ce qu'on veut avec C++/MFC. De plus, le déploiement du framework .Net sur tous les postes clients d'une application .Net est bien plus lourd que celui des dll MFC...

[subzero01]

merci pour tous vos points de vu,
je pense que pour s'attacher aux mfc il faut plus de temps en pratique, et de courage pour commancer de grands projets sous mfc et essayer de les finir sans les abandonner et revenir au .net ce que je fais souvent...

[Mat.M]

mais des fois on trouve que notre application est aussi faisable dans les mfc que dans le .net, mais vue la complexité des fonctions des mfc, je ne choisis pas cette platform meme si j'aime bien m'adapter a choisir mfc quand le choix ne dépend pas de ce que je veux faire.
.

Tout est relatif est discutable ; si tu maitrises un minimum MFC et que tu as des bouts de code pour faire telle ou telle action ( par exemple affichage des images, gestion de réseau) tu est autant performant qu'avec .nET.
Je suis autant performant avec MFC pour développer un projet que je ne le suis avec Visual Basic 6 un outil pourtant sensé réduire les lignes de code..

Et puis est-ce que tu peux faire avec .NET une CScrollView avec splitter et des CFormView ??

si tu as pigé les tenants et aboutissants de MFC tu seras autant performant..
Et puis question performances c'est le jour et la nuit...
Si je le retrouve il y a un site d'une personne qui fait de l'imagerie médicale et il affirme que y'a pas photo avec MFC c'est bien plus rapide et performants qu'avec .NET

[theMonz31]

salut

moi, j'ai fait bcp de MFC , et je fais bcp de .Net depuis quelques temps et je vais faire un retour sur mon expérience, ca servira peut-etre

MFC, c'est rapide... on peut "TOUT" faire... génial

.Net, c'est assez rapide, on peut "Tout" faire... génial

Mouais, et alors me direz vous ?

Je détails....

.Net, tu vas plus vite pour tout ce qui est IHM... gestion des anchors (possibilité d'attacher un composant sur les bords de la fenetre, resizing)... .Net écrase MFC sauf si tu disposes de "composants" maisons

Gestion XML... trop facile en .Net...
LA sérialisation est vraiment aisé... des outils comme XSD.exe sont très utiles.

Création de UserControl (complexe ou pas)... l'utilisation de GDI+ est "quasiment" la meme en C# qu'en MFC... prime à C# pour la simplicité d'utilisation... et simplicité pour le code.

Gestion des images: .Net gagne largement (sauf en perfo)... (avec MFC Visual 6, super la gestion des jpeg, png, etc.... une vraie "galère".

Gestion de plug-in... C'est plus facile en .Net (une archi plug-in en .Net se développe bcp, mais vraiment bcp plus vite qu'en C++... )


Et j'en passe d'autre.

Pour info, j'ai travaillé dans une boite ou nous avons developpé un simulateur en .Net, et beh, ca marchait plutot bien...

Apres, je dirais que tu fais en .Net tout ce que tu faisais en MFC (donc, rien de nouveau), mais seulement, tu le fais juste "PLUS" vite (d'un point de vue développeur)...

Après, dans quel cas utiliser MFC... Moi, j'aurais tendance à dire que C++/MFC par rapport à C# (.Net) s'est le meme combat que C++/C/Assembleur d'il y a presque 20 ans

Si tu veux faire une application qui tourne uniquement sous Windows et que tu l'as crée de rien , je trouve ca "idiot" de ne pas faire du .Net....

Maintenant, si ton appli est super proche du hard, je peux concevoir que tu utilises C++ natif...

Et si au pire, tu as des traitements très particuliers avec un gros besoin en vitesse, tu mets ton code de traitements dans une DLL C++ et après, tu l'utilises en .Net (un de mes cousins sur Caen fait cela pour des traitements d'images... IHM en VB et code de traitement en C++)...

JE crois qu'il faut savoir bien délimiter les contextes d'utilisations, les besoins en perfo etc...

Après, le seul "point" noir de .Net reste l'installation du framework pour fonctionner. Mais bon, Vista est livré avec .Net en natif.. .(ok, j'aime pas vista, mais bon, c'est un fait)

voila... désolé, je me suis un peu laché sur la durée de mon intervention

The Monz, Toulouse

[Mat.M]

.Net, c'est assez rapide, on peut "Tout" faire... génial

Tout faire sauf mixer du code ASM

Après, le seul "point" noir de .Net reste l'installation du framework pour fonctionner. Mais bon, Vista est livré avec .Net en natif.. .(ok, j'aime pas vista, mais bon, c'est un fait)

voila... désolé, je me suis un peu laché sur la durée de mon intervention

The Monz, Toulouse

Je trouve que les développements en .NET c'est pas la pérennité d'un projet...c'est mon point de vue perso..
c'est le même problème qu'il y avait avec ( l'horrible ) Visual Basic..
Microsoft n'arrête pas de changer son Framework c'est un peu comme les composants VBX et OCX qu'il y avait avec Visual Basic.

Et puis 30 Mo à distribuer et à lier avec un simple programme qui ouvre une fenêtre ça fait vraiment lourd

[theMonz31]

salut

le Framework évolue

Et j'entends les gens dire aussi que les MFC n'évoluent pas et que c'est bien dommage, donc... bon, faut choisir...

Après.. pour la pérennité, beh, ca existe depuis 6 ans déja et si tu développes en 2.0 , saches que ca tournera avec n'importe quel framework supérieur sans avoir quoique ce soir à changer.

après, contre l'argument de la taille du framework à installer, je n'ai pas de contre réponse car c'est effectivement dommage. Maintenant, quand tu installes un gros logiciel (style Photoshop, Deluxe Studio (vidéo)etc... tu installes quand meme pas loin de 1 à 2 Go voir plus de bazar, donc, 30 Mo noyé dedans.. c'est pas énorme... maintenant, il est clair que quand tu livres une appli qui fait 1 Mo, ca fait un peu lourd d'avoir 30 Mo de framework à ajouter.... cela dit, une fois le framework installé, c'est fini...

et perso, comme je livre un CD d'install à mes clients, ce n'est pas génant que le Framework .Net 2.0 soit inclus sur le CD


Mais je comprends ton argument qui est loin d'être illusoire !

The Monz, Toulouse

[farscape]

salut

le Framework évolue

Et j'entends les gens dire aussi que les MFC n'évoluent pas et que c'est bien dommage, donc... bon, faut choisir...

Après.. pour la pérennité, beh, ca existe depuis 6 ans déja et si tu développes en 2.0 , saches que ca tournera avec n'importe quel framework supérieur sans avoir quoique ce soir à changer.

après, contre l'argument de la taille du framework à installer, je n'ai pas de contre réponse car c'est effectivement dommage. Maintenant, quand tu installes un gros logiciel (style Photoshop, Deluxe Studio (vidéo)etc... tu installes quand meme pas loin de 1 à 2 Go voir plus de bazar, donc, 30 Mo noyé dedans.. c'est pas énorme... maintenant, il est clair que quand tu livres une appli qui fait 1 Mo, ca fait un peu lourd d'avoir 30 Mo de framework à ajouter.... cela dit, une fois le framework installé, c'est fini...

et perso, comme je livre un CD d'install à mes clients, ce n'est pas génant que le Framework .Net 2.0 soit inclus sur le CD


Mais je comprends ton argument qui est loin d'être illusoire !

The Monz, Toulouse

faux , voir mon blog

[nico-pyright(c)]

en tous cas, ca n'évolue pas aussi vite que .net

[Mat.M]

Il y a une sorte d'hypocrisie chez Microsoft, si on prend en compte le fait qu'ils se soient largement inspirés de Java pour pondre .NET:

Extrait du livre "Atelier Visual C++" ou ( Inside Visual C++ en anglais )chez Microsoft Press de Wingo,Sheperd..

C++ vs. Java
In the last couple of years, there has been a great deal of interest in the Java programming language. Why should you choose C++ over Java? In the first place, a compiled program will always be faster than an interpreted program. Think about a high-performance spreadsheet program with cell formulas and macros. Now imagine the Java virtual machine interpreting the code that, in turn, interprets the formulas and macros. Not pretty, is it? With just-in-time compilation, it's necessary to compile the program every time you load it. Will that code be as good as the optimized output from a C++ compiler?

Execution speed is one factor; access to the operating system is another. For security reasons, Java applets can't perform such tasks as writing to disk and accessing serial ports. In order to be platform-independent, Java application programs are limited to the "lowest common denominator" of operating system features. A C++ program for Microsoft Windows is more flexible because it can call any Win32 function at any time.

Java will be an important language, but we believe it's just another language, not a revolution. If you need an Internet applet or a truly platform-independent application, choose Java. If you need efficiency and flexibility, choose C++.

[nico-pyright(c)]

les choses évoluent.

Dans tous les cas, le CLR c'est pas non plus exactement comme java.
De plus, tu peux faire du p/invoke ou des appels natifs assez facilement, ce qui rend ton code non-portable. Tout comme du C++ finalement.

[Médinoc]

Le seul Wingo-shepherd que je vois sur Amazon est à propos de VC++6, donc vieux.

De plus, .NET contourne le problème de compilation just-in-time grâce au Global Assembly Cache et au Native Image Cache, donc cet argument est toujours valide.

Tout comme l'argument "Lowest Common Denominator", d'ailleurs.