Bonjour,
Je ne sais pas si ma question à lieu d'être ou non.
Je n'ai pas trop développer d'appli sous Windows, donc je me pose des questions sur le C# et C++.
Est-ce que développer une application en C++ avec MFC, aujourd'hui, garantit la pérennité de l'appli ou alors vaut-il mieux développer l'application directement en C#?
 
Microsoft a quelles intentions? N'avoir plus que du .NET?

Bah alors personne n'a d'avis ou d'informations sur ce point presque philosophique?

Oublie les MFC, absolument.  
 
Si tu ne souhaites faire que du Windows, que tu en es sûr à 150%, et que tu chies sur le monde Mac et Linux, alors C# ou même Managed C++ et .NET sont le meilleur choix.
 
Sinon, C++ + un toolkit quelconque (GtkMM 2.5, Qt 4.0 ou wxWidgets 2.6) sont sans doute la meilleure solution.

 
pk ?

- Pas du tout portable: donc tu as tous les inconvénients du c++ sans un des avantages majeurs.
- Plus maintenues par Microsoft. La version 7.0 change 2/3 trucs, mais c'est pas Byzance, et elles ont plein de bugs.
- Aucune intéropérabilité avec la STL: il faut utiliser le système de RTTI MFC, les contenurs MFC, les chaînes CString MFC, etc.
- Ne permettent rien de plus fondamentalement que wxWidgets (qui est maintenu et portable).
- Ont une conception objet très "légère". Très très légere parfois...

parfois inexistante même

Lam's >>

c'est faux ! c'est très portable au contraire
ça marche sous Windows 95, 98, NT, 2000, XP, 2003
 

j'ai déjà mélangé MFC et STL sans souci hein
 

c'est wxWidgets qui ne permet rien de plus que MFC
 

ben quoi, t'aimes pas les macros ?

Ouais, je pensais plus à FreeBSD, à BeOS et à AtheOS là...
Plus sérieusement, je ne veux plus jamais utiliser MainWin, c'était trop... éprouvant.
 

Oui moi aussi. N'empêche que va faire bouffer une std::string ou un std::vector à une classe MFC, et on en reparle.

C'est vrai. Y a juste la lecture de fichiers ZIP, ou de fichier de resources XML dynamique, le parser XML justement, la lecture et sauvegarde de jpeg, png, gif et Tiff, les connexions réseaux simples et efficaces, les Tip providers, etc. etc.
 

Si, et le Modele-Vue aussi, je suis fan.
 
Et arrete de troller. Ca m'ennerve ça, les gens qui prennent le forum pour un jouet, et qui abusent de la patience des autres.

j'ai foutu ma merde content moi

WinMain
stfu n00b
 

on s'en fout, quand on code en MFC, on utilise que MFC
 

et après on me gueule dessus parce que mon plugin traine 150 Mo de runtime derrière lui
 

c'est le modèle Document-Vue, enfin merde, appelle un chat un chat
et rien ne t'empeche d'utiliser un Observer à la place hein
(parce que c'est vrai que le doc-vue.... )
 

et toi arrête de deleter tes posts

MainWin, de MainSoft, qui permet de compiler des programmes Windows sous Solaris et HP-UX. C'est grâce à ça qu'ils avaient pondu IE4 pour Solaris (sisi, souviens toi...).
 

Bof, ça doit prendre dans les 1Mo maximum la lib wxWidgets en static. Et évidemment, les features dont tu n'as pas besoin, tu peux facilement les désactiver...
 
 

Ah ouais, tiens...  

Arf mon topic par en couille   pour changer...
 
le probleme avec le C# c'est le framework, y'a moyen de faire du linkage statique facilement pour ne pas avoir a installer le framework. J'ai vu un log sur le net masi il est payant.

Bon, déjà, tu t'orientes vers du Windows-Only.  
Si tu fais une petite appli ridicule, alors WTL est une bonne option, sinon, la qualité de ton appli doit être en mesure de justifier aux gens de se taper le framework .NET (qui est de plus en plus indispensable sur un PC, soit dit en passant).  

ah, je connaissais pas

honnetement, je vois pas en quoi installer le framework est pénalisant !
j'entends tout le temps "ouais, mais faut installer le framework, et tout.. c'est lourd...". mais en quoi est-ce lourd ?
le framework, une fois installé, ne lance aucun service, ni processus, ni spyware, rien. il installe juste des Mo de dll dans tous les sens et c'est tout ! il ne consomme aucun temps machine quand aucun programme .NET ne tourne.
je veux bien croire qu'il installe des kilos de dll dans tous les sens, mais qui ça gène, à une époque où le moindre 120 Go est à même pas 80 € ?
 
il faut arréter avec cet argument, il ne repose sur rien et de toute façon, comme tu le dis, ça devient de plus en plus indispensable et ça sera intégré dans les futurs windows.
 
mon plugin, j'ai fait le choix de le coder en .NET pour le confort de développement, la sécurité du code et tout. cet environnement est largement supérieur à tout ce qui se fait actuellement (je vais faire grincer des dents, mais c'est ce que je pense), seul Java arriverait à concurrencer s'il n'était pas plombé par un toolkit graphique sensible et controversé (Winform commence là ou Swing se termine à mon humble avis).
 
franchement, se priver de coder sous .NET parce que "c'est lourd", c'est se priver d'un confort de développement et d'utilisation sans précédent.

Sur le principe, je suis d'accord avec toi (et puis il faut pense à l'avenir plutôt qu'au passé: on code une appli qui doit encore être là dans 5/10 ans, comme les meilleurs applis conçues pour Win95, et pas une appli qui aurait du marcher sur les systèmes d'il y a 3/4 ans). MAIS:
 
1. En entreprise, c'est pas aussi simple que ça. Il faut valider les trucs, faire autoriser des packages, etc. Et comme la faille du Jpeg dans Gdi+ l'a montré: plus tu en installes, plus tu t'exposes...
 
2. Pour la multitude de petits softs ridicules qu'on trouve sur le net, il serait complètement aberrant de nécessiter le download d'un paquet de 120 Mo juste pour afficher la température du CPU, faire un screenshot et l'envoyer sur le net, ou bien modifier les dates systèmes de fichiers.
 
C'est un peu un cercle vicieux : personne ne s'en sert, donc le FW n'est pas présent chez tout le monde, donc personne ne s'en sert (un peu le même problème que les DLL de Visual Basic ou que les MFCs il y a quelques années). Mais dans 2/3 ans, ça sera dans les moeurs. Et je crois que ton plug-in pour WinAmp y aura participé, à sa façon.  
 
Tiens, je viens de m'inscrire sur la Beta de Visual Studio 2005 en France : ils vont me l'envoyer sur DVD. . On va voir ce que ça donne.

Faut pas éxagérer non plus, c'est pas une malheureuse dll de 24 Ko qui va démocratiser le déploiement du framework dans les chaumières
Mais merci quand même
 

+1, j'attends avec impatience

Les MFC, c'est le mal !

Moi je préférerais faire du C# personnellement. Mais c'est pas moi qui décide. MAis je peux convaincre... Donc quelqu'un peut me sortir un argumentaire en faveur du C# contre le C++ ?

Un peu gros ...
mon argumentaire :
C# == (C++)++ // en comptant les batons qui se superposent
Donc C# est meilleur que C++.  
CQFD  

C'est faux. Les MFC 8 vont débarquer avec VC++ 8. Corrections de bugs, plus de sécurité, meilleure intégration avec .Net (mélange avec des Winforms possible), plus d'unification entre MFC/STL/ATL.
Faut pas oublier que MS a beaucoup de code qui utilise encore les MFC. Aux dernières nouvelles, ils ont même dit que finalement les nouveautés de Longhorn seraient aussi dispo avec les MFC, et même que les programmes VB tourneraient sur Longhorn.

En terme de focntionnalités pures on peut pas mal critiquer les MFC. Mais ce qui fait la force des MFC, c'est VC++, a savoir l'IDE et ses assistants.
 
Au fait, c'est quoi cette histoire de 120 Mo ?

C'est pas si simple. C# 2.0 why not, C# et .Net 1.1, faut voir. Ca dépend de:
- quand tu vas commencer à développer
- combien de temps vous allez développer cette appli, date prévue de 1° release
- le niveau / background des développeurs
- le type d'application développée
- les clients visés
- ...

Je suis tout seul pour développer, c'est dans le cadre de mon stage, il me reste a peu pres 5 mois.
Je viens de finir le cahier des charges.
C'est une appli de collecte d'informations (requetes WMI, recup d'info dans le Registre, recup de fichiers log, config, scan des ports...)
les clients : des techniciens en info
 
Le C++ est plus logique car l'appli doit etre simple et rapide à installer, genre juste un .exe (le framework fait environ 20Mo )
Maintenant, le C# c'est plus simple pour moi qui ai programmé surtout sous linux... (pas de MFC et de fonctions à 2 balles)

Oula, c'est une longue histoire, assez triste et assez pénible à raconter. Disons que NullSoft a sorti un logiciel qui permet de lire des MP3 et qui s'appelle WinAmp. Ce logiciel est optimisé, léger et efficace.  
 
Or, il y a des barbares qui lui collent des plug-ins avec des IHMs codées en VB ou en C#, et qui ont besoin du framework .NET pour fonctionner. Donc si tu veux utiliser ce type de plug-in, il faut allourdir ton Winamp de 120 Mo de DLLs.  
 
Mais bon, il se dit dans les salons à la mode que le plug-in en vaut la peine...
 

T'as regardé du coté de la WTL ?

 
Non pas encore. Mais dans la boite apparemment ils utilisent MFC

MFC et WTL ne sont pas incompatibles. On peut utiliser les 2 en même temps dans une même appli en principe.  
La WTL est :
 - plus propre
 - bcp plus légère
 - bcp plus rapide
Mais elle ne remplace pas entièrement les MFC et est moins bien documentée.

Et surtout c'est pas supporté, c'est les mecs de ATL qui se sont amusés à faire la même chose mais pour les fenêtres classiques. Un développement interne à MS en somme. MS a décidé de mettre ça en... open source, sur sourceforge, et ne supporte pas ce produit.
Les concepteurs de la WTL la présentent ainsi:

pour ceux qui ont du mal, les créateurs même de la WTL disent qu'il faut être un guru des MFC et de la prog Win32, et avoir de sérieuses bases en C++ pour se lancer dans l'aventure. Et puis utiliser pour ton projet un produit que MS a refusé de supporté, c'est dur à argumenter.
 
Pour les 120 Mo j'ai toujours pas compris, pour moi le framework fait dans les 23 Mo.
 

Alors, dans le cadre d'un stage, pour ton avenir personnel, je pense que tu as intérrêt à convaincre d'utiliser C# et ainsi de pouvoir ajouter cette ligne à ton CV, c'est pas mal pour la suite. Ca c'est pour toi.
Après au niveau du projet, faut voir ton background C++ / dev Windows. Si tu n'a jamais touché de dev Windows, et que t'es légé en C++, tu seras clairement plus productif en C#, surtout que des trucs comme WMI c'est clairement plus complexe en C++.
Après il faudra installer le framework. Mais faut choisir : les MFC sont bien plus longues à appréhender que .Net, surtout pour un stagiaire (c'est pas une critique envers toi, tu n'as pas à rougir d'être né sans savoir programmer en MFC). Et celà, ce sera vrai pour chaque stagiaire, c.a;d que le prochain stagiaire qui reprendra ton travail sera opérationnel plus rapidement.
Bref, C# c'est plus simple, l'IDE est meilleur, etc...
Mais C++ en tant que C++ a ses avantages aussi face à C#. Mais en tant que stagiaire, je doute que tu ais suffisament de pratique de C++ pour regretter certaines fonctionnalité en C# (tjrs pareil, te vexe pas). Donc finallement, à la question développerais-tu mieux en C++ qu'en C#, on peut raisonnablement répondre non, surtout que le stagiaire, y'a personne qui va se bousculer pour t'aider et te corriger dans ton code / tes pratiques.
Donc à mon avis, tout plaide pour C#, et tu as intérrêt à choisir C# car ça fait mieux sur le CV, c'est comme ça.
On pourrait débattre plus en faveur de C++/MFC si un spécialiste MFC bossait avec toi, et que tu devais utiliser des libs tierces en C++. Mais apparement c'est pas le cas.

Merci pour toutes ces infos    
 
Pour le C#, c'est clair que je suis beaucoup plus à l'aise. J'ai fais un proto de l'appli en C# et C++. En C# ca m'a pris environ 1j et en C++, y'a des trucs que je n'arrive toujours pas à faire correctemnt au bout de plusieurs jours
Maintenant, il faut les convaincre car eux ils s'en tappent un peu que je préfére et que je sois plus efficace dans l'un ou l'autre. Je veux pas passer pour un neuneu non plus, qui sait faire que programmé dans un langage (je sais quand meme programmé en C, Java et C++ sous linux et surement d'autres truc que j'oubli...). C'est sur que si le projet est en C++ j'y arriverais mais pas dans les même délais

 
Ca fait partie des arguments qu'ils sont susceptibles d'écouter.
 
Les délais coûtent cher.
 
Prévois aussi une estimation des coûts (en jour-homme) de maintenance et d'évolution. Ca peut les convaincre.

ça c'est normal

ça ça l'est moins.
Essaye de jouer un peu avec WMI avec C# et C++. Fait la même (toute petite) appli, note bien le delais consacré à chacune d'elle.
http://msdn.microsoft.com/library/ [...] mputer.asp
http://dotnet.developpez.com/tutoriels/wmi1/

 
c'est ce que j'ai fait, je le dit dans mon poste précédent.
Résultat en C++, je met 3 à 4 fois plus de temps.
Mais je découvre aussi (j'avais jamais touché au MFC avant, en fait c'est plus de la bidouille que je fais, je ne suis pas satisfait du code), donc on se dit qu'au début je vais lutter mais apres ca roulera, enfin on espère. En C# malgré que je découvre aussi, j'arrive à faire ce que je veux rapidement et le code est impec   à mon gout.

J'avais pas compris que tu avais fait du WMI. Faut passer par COM, et si tu piges pas bien ce que tu fais, c'est facile d'avoir des memory leaks et de plantages à cause d'un VARIANT mal utilisé.

 
Ah les VARIANT... je me suis bien "amusé", enfin pris la tete, avec.
 
Par exemple, j'ai une fonction WMI qui retourne un VARAINT mais apres je ne sais pas quel champ (type) récupérer dedans. Ma fonction me retourne un CIMTYPE mais je ne sais pas l'utiliser pour connaitre le type retourné et donc le champ à récupérer dans le VARIANT (car bstrVal marche pas à tous les coups, j'ai aussi des booléen, des int...).

Il lire mon_variant.vt qui te donne le type contenu dans le variant.
http://msdn.microsoft.com/library/ [...] 6_7zdz.asp
Faut pas oublier de libérer le pointeur dans le cas d'une BSTR...

 
Ah merci
Un clear sur le variant ca ne suffit pas?
Tu fais un free?

Au sujet du .NET FW, il devrait logiquement être inclus en standard avec Longhorn, donc la question ne se posera même plus...

si ta BSTR est possédée par la variant, oui ça suffit. Si tu as créé / manipulé la BSTR à côté, et utilisé un ref dessus (VT_BYREF), alors c'est à toi de gérer sa désallocation.
Pour simplifier le code, jette un oeil aux wrappers _variant_t et _bstr_t.

 
Ouais j'ai deja sorti ca comme argument. Mais avant que Longhorn sorte et que les entreprise l'adopte...