Inscrivez-vous gratuitement
pour pouvoir participer, suivre les r�ponses en temps r�el, voter pour les messages, poser vos propres questions et recevoir la newsletter
Application MFC contre pure Win32
Je viens de VB, je voudrais d�velopper des applis tr�s gourmandes en resources et VB est pas adapt� pur �a. Mais j'ai l'impression que MFC mange pas mal de resources aussi: � chaque fois que j'ai utilis� des logiciels utilisant MFC quand je leur en demande trop �a rame ou �a plante carr�ment windows. Idem avec Delphi 7 (Delphi 4 a l'air mieux).
Donc reste Win32.
Est-ce que quelqu'un a d�velopp� intens�ment autant en Win32 qu'en MFC pour donner un avis le plus objectif possible ?
objectivement, plus tu rajoutes de couches, et plus ca risque d'etre lent (en admettant que le developpement sans couches soit compl�tement maitris�)
Re: Application MFC contre pure Win32
tu ne t'es jamais dit que si les programmes plantais en VC et delplhi c'est que ca venait peut etre de toi et non des environnement (surtout si tu as les mauvaises habitudes de VB) ?Envoy� par albertl
salut,
et pour en rajouter un petite couche ,
1) je suis d"accord avec la drogue c'est mal
2)A niveau de complexit� �gale de l�interface en MFC en win32 ,
(D�j� il faut avoir envie).
Je ne suis pas du tout convaincu du plus de rapidit� en win32.
Les MFC n��tant pas tr�s loin des apis de base �.
Pour tes probl�mes je pencherais plut�t pour un mauvais codage des traitements
Ce qui est affirm� sans preuve peut �tre ni� sans preuve Euclide.
Les conversions num�riques en C,C++,C++/CLI
DLL d'extensions : �criture d'un plug-in de classe
D�marrer avec les MFC 2/2
Cr�ation d'un ActiveX MFC
Int�gration d'une imprimante PDF pour �ditions automatis�es
Migrer du code de Visual C++ 6.0 vers Visual C++ 2005
D�marrer avec les MFC sous Visual C++1/2
la Faq Visual C++ 500 Q/R,Mon blog
Aide en Ligne MFC
Cours et tutoriels C++ - FAQ C++ - Forum C++.
Et encore une petite couche
Un programme MFC bien cod� sera plus performant que du Win32 cochon. Idem avec Delphi.
Sacant qu'en Win32 il est plus facile de coder comme un cochon qu'avec les 2 autres...
Delphi est une surcouche � Win32 (VCL), MFC est une surcouche � Win32. Si ces 2 l� posent probl�me, c'est pas sur qu'attaquer directement Win32 soit la solution. C'est peut �tre un d�faut d'utilisation de Win32.
Planter Windows avec une simple appli MFC, sous Windows NT en tous cas, je suis sceptique.
+1salut,
et pour en rajouter un petite couche ,
1) je suis d"accord avec la drogue c'est mal
2)A niveau de complexit� �gale de l�interface en MFC en win32 ,
(D�j� il faut avoir envie).
Je ne suis pas du tout convaincu du plus de rapidit� en win32.
Les MFC n��tant pas tr�s loin des apis de base �.
Pour tes probl�mes je pencherais plut�t pour un mauvais codage des traitements
pour tout ce qui est gestion d'interfaces, ca se ressemble beaucoup (que les mfc utilisent les apis), sauf qu'avec les MFC, c'est BEAUCOUP plus simple
L� o� la lenteur risque de se sentir, c'est dans les surcouches s�curis�es de classes (comme les CString (meme si c'est un mauvais exemple)), le fait de rajouter les tests de d�bordements, de r�allocation, etc ... font que ca rajoute du code et si ca rajoute du code, ca rajoute des traitements, etc ...
Re: Application MFC contre pure Win32
Je parlais des programmes des AUTRES moi c'est pas possible j'en ai pas encore vraiment fait � part des bouts pour apprendre
Et les autres je parle pas de programmes amateurs forc�ment. Par exemple foxmail qui est un excellent logiciel d'email est en Delphi si je lance d'autres applis Delphi 6 ou 7 �a peut planter si j'ai trop d'applis d�j� ouverts � cause de manques de resources. Et pr�cision je parle pas de perf, la perf est correcte je parle des resources syst�mes. Des applis MFC j'ai plus trop de noms en t�te c'est moins pire que Delphi mais c'est pas terrible non plus je trouve. Les applis win32 elles m'ont l'air de jamais faire �a m�me si l'interface graphique est tr�s riche.
Quel OS ?�a peut planter si j'ai trop d'applis d�j� ouverts � cause de manques de resources
Si t'as plus de m�moire, Win32 ou pas, �a marchera pas.
Sur une appli genre foxmail, je suis pas s�r que 10 boutons et une lisybox soit ce qui prend le plus de ressources. C'est des choses comme lire et afficher une page HTML, g�rer la base de donn�es de contacts, etc... Va embarquer un composant IE pour afficher une page HTML en C/Win32...
je confirme, c'est pas rigolo
Je suis sous Win98 (j'ai XP mais les failles de s�cu d� au RPC sous XP qu'on peut pas d�sactiver me font peur). J'ai 400 Mo de Ram, le probl�me c'est pas la m�moire globale le probl�me ce sont les resouces syst�mes qui sont limit�s par conception de Windows. Je sais pas si sous XP c'est la m�me chose mais de toute fa�on �a change rien: j'ai des clients sous win98 et m�me win95 aussi faut que �a tourne sous Win98.
J'ai pas dis que foxmail tournait pas je dis que si tu lances plein d'autres applis �a peut planter � cause des resources. En fait m�me un b�te utilitaire de copie d'�cran genre MWsnap d�velopp� en delphi peut cr�er le m�me probl�me. Des applis win32 - j'en ai justement compil� une avec plein de treview de grids etc... qui est aussi riche que foxmail bouffe pas autant. Et MFC j'ai l'impression c'est entre les deux. Ce que je cherche c'est des infos sur la consommation de resources syst�mes pas sur la perf ou la consommation globale en m�moire.
C'est vrai c'est un argument. Mais c'est pas impossible d'apr�s ce que j'ai pu voir. Venant de VB je sais ce que veut dire plus simple: plus simple pour faire des choses simples mais pas forc�ment plus simples pour faire des choses compliqu�esVa embarquer un composant IE pour afficher une page HTML en C/Win32.... Je trouve que Delphi sur ce point est mieux que VB: pour des trucs simples c'est prise de t�te mais pour des trucs compliqu�s c'est plus simple que sur VB et encore quand c'est possible sous VB. Donc je suis pas s�r que plus simple sous MFC �a va pas se traduire par plus compliqu� pour autre chose genre attaquer les objets du shell.
la consommation des ressources est due a l'utilisation d'objets GDI comme les menus ,les brush ,les dc , les pen etc...
le nombre de ressources allou�es par OS n'est pas le m�me ,j'en ai d�j� fais l'exp�rience .
XP est l'os qui en autorise le plus par rapport a win95/98/ME .
En MFC une cause d'utilisation importante de ressources c'est le nombre de document template d�clar� dans le cas d'un programme MDI .
Chaque template consomme des ressources li�s au menu ...
Ce qui revient a dire que chaque fen�tre peut avoir son propre menu ...
Personnellement j'ai r�solu ce probl�me en red�finissant le m�canisme d'ouverture des fen�tres en utilisant toujours le m�me menu.
Sinon une bonne habitude est de r�server le minimum de ressources GDI n�cessaires, et de rel�cher les objets GDI secondaires et les recr�er � la vol�e.
Exemple j'ai fais un activex de type static qui peut �tre pr�sent une 50 de fois sur une fen�tre, si dans l'activex je d�clare mes brush pen etc en permanence les ressources vont chuter de part le nombre d'activex pr�sents en m�me temps.
Solution adopt�e : cr�er les objets GDI uniquement au moment du dessin et les rel�cher ensuite.
Pour finir sous XP ou NT dans le gestionnaire des taches tu peux contr�ler le nombre d'objets GDI utilis�s par ton programme.
[edit]
ps:
ce probl�me des ressources est un vrai probl�me dans le cas ou un programme doit �tre distribuer sur plusieurs OS.
Dans mon cas j�ai un programme qui a plus de 120 documents templates d�clar� mais un seul menu ressource consomm�.
je ne sais pas comment �a fonctionne sous delphi ou vb dans un contexte equivalent MDI
sur la gestion des ressources au niveau menu ,
mais l�avantage des MFC c�est que tu peux pratiquement reprendre la main a tous les niveaux
pour enrichir ou intervenir sur le fonctionnement de base .
[/edit]
Ce qui est affirm� sans preuve peut �tre ni� sans preuve Euclide.
Les conversions num�riques en C,C++,C++/CLI
DLL d'extensions : �criture d'un plug-in de classe
D�marrer avec les MFC 2/2
Cr�ation d'un ActiveX MFC
Int�gration d'une imprimante PDF pour �ditions automatis�es
Migrer du code de Visual C++ 6.0 vers Visual C++ 2005
D�marrer avec les MFC sous Visual C++1/2
la Faq Visual C++ 500 Q/R,Mon blog
Aide en Ligne MFC
Cours et tutoriels C++ - FAQ C++ - Forum C++.
Et pourtant... En passant de 98 � Nt tu te prot�ge d�j� de 50% des virus existants. NT g�re la protection, et si tu t'en sert, c.a.d que tu ne travailles pas en Administrateur eh ben y'a plus grand chose qui passe : le
fondemment de tout virus c'est sa capacit� de reproduction => capacit� � infecter d'autres exe. Avec Program files / system32 / bdr en lecture seule quand on est utilisateur limit� (& NTFS), le virus ne peut pas infecter l'ordi... Moi je travaille comme �a, sans anitivirus, et quand j'en fait tourner un une ou 2 fois par an, il me trouve 2/3 virus dans un .zip mais rien n'est infect�. Et depuis XP SP2, Xp est l'OS le + s�r de MS.
Y'a 2 cat�gories de Windows : la lign�e Win95/98/Me et la lign�e NT/2K/XP/2K3. La premi�re lign�e est � mon sens la principale cause de critiques (justifi�es) sur les OS Microsoft. La seconde c'est une autre histoire. Par exemple sous 95 les ressources GDI sont communes � tous les process, et le tas GDI est de 64Ko. Donc tous les process disposent de 64Ko de ressource GDI. Sachant qu'un DC p�se 800 octets, c'est vite grinot�, et une seule appli trop gourmande peut tout fouttre en l'air.J'ai 400 Mo de Ram, le probl�me c'est pas la m�moire globale le probl�me ce sont les resouces syst�mes qui sont limit�s par conception de Windows. Je sais pas si sous XP c'est la m�me chose mais de toute fa�on �a change rien: j'ai des clients sous win98 et m�me win95 aussi faut que �a tourne sous Win98.
Sous NT c'est une autre histoire : chaque process dispose de son tas GDI.
Cela dit une fois j'avais essay� de tester cette limite sous Win98 SE, et j'ai rien constat�. Win98 SE se veut avoir corrig� pas mal de limitations de Win95, je me demande si �a en fait pas partie.
Faut comparer ce qui est comparable. Il faut faire 2 fois la m�me appli. Maintenant c'est vrai qu'en Delphi y'a une particularit� : chaque classe Win32 est subclass�e (avec un T ajout� devant le nom de la classe : TButton, TEdit, ...) et donc �a consomme des ressources GDI. Mais c'est pas le cas en MFC.J'ai pas dis que foxmail tournait pas je dis que si tu lances plein d'autres applis �a peut planter � cause des resources. En fait m�me un b�te utilitaire de copie d'�cran genre MWsnap d�velopp� en delphi peut cr�er le m�me probl�me. Des applis win32 - j'en ai justement compil� une avec plein de treview de grids etc... qui est aussi riche que foxmail bouffe pas autant.
Le mieux est de faire ton propre benchmark. Y'a des outils pour traquer les ressources GDI:Et MFC j'ai l'impression c'est entre les deux. Ce que je cherche c'est des infos sur la consommation de resources syst�mes pas sur la perf ou la consommation globale en m�moire.
http://msdn.microsoft.com/msdnmag/issues/03/01/GDILeaks/default.aspx
http://msdn.microsoft.com/msdnmag/issues/01/03/leaks/default.aspx
Mais n'oublie pas de comparer ce qui est comparable...
Biens�r que c'est possible. Tout ce qu'une surcouche � Win32 peut faire, Win32 le peut aussi... Mais moi j'ai fait le test d'automatiser Excel � la main : 5 lignes de VB deviennent 100 lignes de C.C'est vrai c'est un argument. Mais c'est pas impossible d'apr�s ce que j'ai pu voir.Va embarquer un composant IE pour afficher une page HTML en C/Win32...
C'est de domaine o� VB est roi. Delphi a l'air tr�s sympa aussi. Avec les MFC c'est d�j� plus p�nible, et en C argh... Mais l� on est dans COM.Donc je suis pas s�r que plus simple sous MFC �a va pas se traduire par plus compliqu� pour autre chose genre attaquer les objets du shell.
Je partage l'avis des personnes qui m'ont pr�c�d�es ( Farscape, Aur�lien)
Maintenant pour ton rendre compte il suffit de jeter un coup d'oeil dans les sources MFC .....
Effectivement il ya des traitements en interne ( toujours si on d�cortique les sources MFC ) qui peuvent apporter des lourdeurs , des Threads qui sont cr�es on ne sait pas trop pourquoi.
Maintenant rien ne t'emp�che de cr�er une appli de base win32 et cr�er tes propres classes CButton , CEdit en s'inspirant du code source MFC...
Pour certaines applis mieux vaut prendre win32 : les jeux , les applis syst�mes.
Si c'est une appli en grande partie avec GUI , alors MFC est vraiment mieux car cela encapsule une bonne partie du travail...
Oui mais une appli d�velopp�e en win32 �a peut -�tre pareil surtout si tu utilises des connections r�seau.....� chaque fois que j'ai utilis� des logiciels utilisant MFC quand je leur en demande trop �a rame ou �a plante carr�ment windows.
A quoi peut-on voir �a Aur�lien c.a.d comment sais-tu q'un DC cela p�se 800k ?Par exemple sous 95 les ressources GDI sont communes � tous les process, et le tas GDI est de 64Ko. Donc tous les process disposent de 64Ko de ressource GDI. Sachant qu'un DC p�se 800Ko, c'est vite grinot�, et une seule appli trop gourmande peut tout fouttre en l'air.
Merci � tous pour les pr�cisions sur les ressources. Il faudrait effectivement que je compare ce qui est comparable.
Pour Delphi m�me en �tant d�butant sur la plateforme je suis comme m�me capable de tout recr�er en run-time - c'est � dire sans utiliser l'�diteur visuel - et effectivement cr�er par exemple un seule ressource de menu popup au lieu de 36000 avec l'interface visuel. N�anmoins �a reste des VCLs donc je suppose que �a consomme toujours plus que du win32 natif.ce probl�me des ressources est un vrai probl�me dans le cas ou un programme doit �tre distribuer sur plusieurs OS.
Dans mon cas j�ai un programme qui a plus de 120 documents templates d�clar� mais un seul menu ressource consomm�.
je ne sais pas comment �a fonctionne sous delphi ou vb dans un contexte equivalent MDI
sur la gestion des ressources au niveau menu ,
mais l�avantage des MFC c�est que tu peux pratiquement reprendre la main a tous les niveaux
pour enrichir ou intervenir sur le fonctionnement de base .
En MFC je sais pas si je vais �tre capable tout le monde a l'air de dire que c'est plus facile mais perso je lis du code win32 je comprends mieux que du code MFC. C'est vrai que rien qu'un squelette Win32 �a fait un nombre de lignes effrayant mais quand on regarde de plus pr�s c'est juste des lignes de d�clarations de propri�t�s - un peu comme java qui se met � d�clarer des propri�t�s d'interface dans du XML - le reste c'est un switch d'�v�nement donc c'est pas la mer � boire � comprendre. Alors que le MFC c'est plus succint mais c'est une bo�te noire je comprends pas bien ce qu'il fait avec sa salade
Oups, ma fourche a langu�, c'est 800 octets biens�r. Comment tu vois �a ? Ben tu le vois pas, tu le lis dans une doc MS et tu le crois sur paroleA quoi peut-on voir �a Aur�lien c.a.d comment sais-tu q'un DC cela p�se 800k ?
http://msdn.microsoft.com/library/en-us/dnwui/html/msdn_classy32.aspThe CS_OWNDC style brings out a difference between Windows NT and Windows 95. In Windows NT, the Win32 subsystem has the same available address space (4 GB) as any other Windows NT process. The application can use 2 GB of this address space. Each window instance that has the CS_OWNDC style takes up about 800 bytes of storage. Obviously, this is not a problem under Windows NT. However, things are much different under Windows 95. Windows 95 has a 64K local heap for GDI. Although many data items are no longer stored in this local help, DCs still are. This means that each window instance that has the CS_OWNDC style takes up 800 bytes of this precious memory space. As a result, applications that target Windows 95 should use the CS_OWNDC class style sparingly. Windows 95 may move DCs out of the local heap in the future.
Apr�s recherche, apparement y'a pas une unique pile GDI de 64Ko mais plusieurs ce qui explique que la saturation ne soit pas trop fr�quente:
http://www.ascensionlabs.com/general_WindowsResources.htm
c'est t'es un ad�pte du C++, et des templates, tu peux essayer WTL. je crois qu'elle se situe entre Win32, et les MFC, super l�gere et pas mal de classes pour les nouveau contr�les, t'es m�me la possibilit� d'avoir des super GUI avec les docking panel avec seulement quelques classes.
c'est vrai qu'elle a �t� abondonn� par Micorosoft, elle continue toujours de survire gr�ce � des guru, voir le site http://wtl.sourceforge.net. il y pas mal de tutorial sur http://www.codeproject.com.
Une derni�re choses, elle est archi non portable.
R�pondre avec citation
Partager