Version imprimable
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é)
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) ?Citation:
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
:D
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.
+1Citation:
Envoyé par farscape
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 :D
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 ...
Je parlais des programmes des AUTRES moi c'est pas possible j'en ai pas encore vraiment fait à part des bouts pour apprendre :)Citation:
Envoyé par la drogue c'est mal
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 ?Citation:
ç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 :D, avec les mfc, ca devient tout de suite vachement simple ...Citation:
Envoyé par Aurelien.Regat-Barrel
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.Citation:
Envoyé par Aurelien.Regat-Barrel
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ées ;). 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.Citation:
Va embarquer un composant IE pour afficher une page HTML en C/Win32...
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]
:D
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 : leCitation:
Envoyé par albertl
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.Citation:
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.Citation:
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:Citation:
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.Citation:
C'est vrai c'est un argument. Mais c'est pas impossible d'après ce que j'ai pu voir.Citation:
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.Citation:
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...
:D
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..... :wink:Citation:
à 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 ? :DCitation:
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.Citation:
Envoyé par farscape
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 :D
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 parole :)Citation:
Envoyé par mat.M
http://msdn.microsoft.com/library/en-us/dnwui/html/msdn_classy32.aspCitation:
The 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.