Je cherche à connaître l’implantation mémoire des différents « segments » lorsque j’ai chargé une application sous le debugeur GNU. Autrement dit, connaître la zone de mémoire attribuée à chaque sous-ensemble (CODE, BSS, DATA, STACK…). Quelqu’un sait comment faire ? (dites oui 
)
bas vi, et c’est bien pratique !!!
Intéressant ça, je ne connaissais pas cette notion de “placement”.
pour les constructeur j’utilise… tada :
Le “placement new”, qui necessite un new overloader :
et permet de passer une adresse, ou n’importe quoi a un new !
ou sinon, je fait le sale : rien dans le constructeur, malloc, type cast et Bob->IsYourUncleInit();…
from msdn :
An option in the syntax allows specification of placement (see Syntax for new Operator). The placement parameters can be used only for user-defined implementations of operator new; it allows extra information to be passed to operator new. An expression with a placement field such as
T *TObject = new ( 0x0040 ) T;
is translated to
T *TObject = T::operator new( sizeof( T ), 0x0040 );
The original intention of the placement field was to allow hardware-dependent objects to be allocated at user-specified addresses.
[quote]je les :
a) preinstancie quand je peux.
j’instancie tout au moment du chargement : ca me permet de dire que le traitement se fait sans alloc, donc plus simple.
c) ou sinon je fait une preallocation du nombre moyen de classe dont j’ai/peux avoir besoin, et tant que j’ai un espace libre, je n’ai pas de nouvelle alloc, et mon allocation tiens plus de l’assignation de pointer, que de la vrais alloc : vu que la memoire est deja dispo, et si il n’y a plus de place dans mon tas j’en realloue un block de N, en couinant comme un gorret, comme ca je peux regler pile-poils mes besoins memoires, et savoir exactement ce que je consomme et comment 
vala comment je fais[/quote]
Et les constructeurs, tu les appelles quand ?
Je comprends bien l’intérêt de l’allocation sans passer par un appel système il est clair que si tu alloues/libères un buffer à chaque trame IP (exemple d’une appli réseau), le débit moyen sera poussif 
…
je parle de C,
et si c’est optimum en terme d’utilisation de memoire : car quand tu a bien tuner ton application. tu as exactement la memoire necessaire, tu peut meme te permettres de faire tourner toute ton appli avec un seul malloc et un seul free !
et ca c Bo !
et bon oui, soit ca marche pas pour grands chose d’autres que des applis avec des entree presques pas variable !
et perso, en cours de dev et debug : j’ai tendance a gacher enaurmement de memoire : genre presque 64Mo, tu 'ois :-|, une fois que c’est finit par contre c’est vrais que j’aime pas quand ca depasse !
Dis, c0unt 0, je n’y connais pas grand chose en C++, mais d’instinct, je me dis que ton truc n’est pas du tout optimal en terme d’utilisation memoire?
Pour moi, Optimal, c’est moins j’en utilise, mieux je me porte.
LoneWolf
Le C, au moins, on sait ce qu’on alloue
je les :
a) preinstancie quand je peux.
j’instancie tout au moment du chargement : ca me permet de dire que le traitement se fait sans alloc, donc plus simple.
c) ou sinon je fait une preallocation du nombre moyen de classe dont j’ai/peux avoir besoin, et tant que j’ai un espace libre, je n’ai pas de nouvelle alloc, et mon allocation tiens plus de l’assignation de pointer, que de la vrais alloc : vu que la memoire est deja dispo, et si il n’y a plus de place dans mon tas j’en realloue un block de N, en couinant comme un gorret, comme ca je peux regler pile-poils mes besoins memoires, et savoir exactement ce que je consomme et comment
vala comment je fais
Tu fais comment lorsque tu as à instancier une classe ?
ouais bas n’empeche que moi j’ai toujours un allocateur memoire maison…
qu’en c’est en debug, ca fait tout plein de truc autours qui aident
qu’en c’est en release, ca fait juste malloc, des fois, meme, vachement moins :nuts:
(et en Debug, je cherche pas les perfs, je cherche les boug)
et entre nous, si tes problem de perfs sont lies a des malloc/free : c’est mal, theoriquement, a partir du moment ou tu a charger tes donnees, tu devrais plus faire d’alloc, jamais
[quote][quote]
Ouais. Personnelement, j’en suis revenu, de VC++: Deja 1, le Hello world de 200 lignes, ca fout les boules direct.[/quote]
Tsssss. N’importe quoi. MS a fait la plus grosse connerie du monde en faisant dire hello world a son appli du wizard.
[/quote]{cut} Admettons pour Hello World.
[quote]Quand a ce qui est de la compil les lib faut les mettre a la mano ou en cliquotant pareil qu’en gcc tu les met en ligne de commande. Ca marche autant a tout les coups et si ca marche pas c’est que t’as ptet pas pige un truc dans l’interface. Le fait que le reboot semble corriger le probleme est une pure coincidence.[/quote]Bah j’y suis pas arrive. Je le disais a la fin du post, je suis pas doue avec les environnement clickodrome
Moktar
[quote]Mmmhhhh… ça veut dire quoi explicite ? tu mets l’option en ligne de commande et donc c’est explicite et réalisé ? bah non, essaies l’outil « nm » avec ses différentes options et tu verras qu’elles ne fonctionnent pas toutes (c’est un exemple hein, et parce que je l’ai utilisé hier). C’est rigolo de croire que, parce qu’on tape en ligne de commande c’est hyper puissant et sans problème…[/quote]Bah a chaque fois que j’avais une merde avec gcc, c’est parce que j’avais oublie un truc dans la ligne de commande. C’etait de MA faute. Alors que VC++, j’avais tout bien renseigne dans les champs lib, include et tout ca, et ca marchais pas. Voila quoi
[quote]Ca me fait penser à la réflexion d’un formateur qui décrivait un outil (en ligne de commande) et tenait ces propos : « l’outil machin est super puissant, il est tellement puissant que toutes les fonctionnalités ne sont pas documentées » hhahahhAHAHAHA comment je lui ai jeté des pierres[/quote]Ouais, c’est completement con, comme remarque. C’est comme le prof de DESS, arrive en salle de TP avec des PC sous win2000, et qui, pour se la peter, nous fait:
« Vous savez pourquoi il faut faire crtl alt sup pour lancer une session NT? »
« _Non »
« Parce que ca reboot l’ordinateur »
Eclat de rire general, ca a fait un effet, c’est clair, mais pas celui escompte ;))
[quote]MFC : bah ce n’est pas si mal que ça, il faut juste utiliser les ressources adéquates et puis je préfère utiliser les ressources des MFCs que la STL (STL == caca, pour ceux qui ont débuggés des gros trucs basé sur la STL comprennent sûrement), sinon l’environnement GNU, il apporte quoi comme bibliothèques sympa ?[/quote]J’avoue que je ne suis pas un specialiste C++ (pas du tout en fait), mais en lib GNU, j’aime beaucoup ncurses. La doc est un bonheur a l’etat pur.
LoneWolf
Ouais, c’est vrai, c’est pas du clickodrome non plus, ncurses :))
[quote][quote]
Ouais. Personnelement, j’en suis revenu, de VC++: Deja 1, le Hello world de 200 lignes, ca fout les boules direct.[/quote]
Tsssss. N’importe quoi. MS a fait la plus grosse connerie du monde en faisant dire hello world a son appli du wizard. Pourquoi? Pour ce genre de reactions. C’est pas une appli qui fait hello world, c’est toute une base avec tout joli, bien organise pour faire une appli complete. Il y a beaucoup beaucoup plus que hello world dedans. Ils auraient mieux fait de faire un truc qui disait rien et qui faisait la meme chose. En VC++, comme avec gcc, hello world se resume a “hello world” >> cout; Maintenant si on veut critiquer MFC c’est une autre histoire… mais ca a rien a voir avec VC++.
Quand a ce qui est de la compil les lib faut les mettre a la mano ou en cliquotant pareil qu’en gcc tu les met en ligne de commande. Ca marche autant a tout les coups et si ca marche pas c’est que t’as ptet pas pige un truc dans l’interface. Le fait que le reboot semble corriger le probleme est une pure coincidence.
[Edité le 24/1/2003 par GloP] [/quote]
Je confirme ( cout
Tsssss. N’importe quoi. MS a fait la plus grosse connerie du monde en faisant dire hello world a son appli du wizard. Pourquoi? Pour ce genre de reactions. C’est pas une appli qui fait hello world, c’est toute une base avec tout joli, bien organise pour faire une appli complete. Il y a beaucoup beaucoup plus que hello world dedans. Ils auraient mieux fait de faire un truc qui disait rien et qui faisait la meme chose. En VC++, comme avec gcc, hello world se resume a « hello world » >> cout; Maintenant si on veut critiquer MFC c’est une autre histoire… mais ca a rien a voir avec VC++.
Quand a ce qui est de la compil les lib faut les mettre a la mano ou en cliquotant pareil qu’en gcc tu les met en ligne de commande. Ca marche autant a tout les coups et si ca marche pas c’est que t’as ptet pas pige un truc dans l’interface. Le fait que le reboot semble corriger le probleme est une pure coincidence.
[Edité le 24/1/2003 par GloP]
Rhhhoooo même pas vrai (m’en branle hein, ça fait bien 4 ans que je n’ai pas développé sous VC++) : cf ici pour un exemple de Hello World en VC++ 
[quote]Ensuite, pour compiler un programme avec une librairie particuliere avec gcc, tu dois etre explicite, genre -I/usr/local/include/canna -L/usr/local/lib -lcanna (Librairie de gestion du japonais, c’est juste un exemple hein ;))
Avec VC++, tu rajoute les repertoires, tu compiles. ld error. Tu bricoles, bidouille… RIEN. RAH EUH. Tu reboot et ca marche (quoi que la premiere fois, ca marchais pas). FAIS CHIER![/quote]
Ha ? je n’ai jamais eu ce problème… mais je peux trouver des problèmes avec l’environnement GNU hein 
et des pbs super chiants
[quote]Je dois pas etre doue, avec les interfaces graphique a clickodrome, je crois.
LoneWolf
Vive la compilation explicite.[/quote]
Mmmhhhh… ça veut dire quoi explicite ? tu mets l’option en ligne de commande et donc c’est explicite et réalisé ? bah non, essaies l’outil « nm » avec ses différentes options et tu verras qu’elles ne fonctionnent pas toutes (c’est un exemple hein, et parce que je l’ai utilisé hier). C’est rigolo de croire que, parce qu’on tape en ligne de commande c’est hyper puissant et sans problème…
Ca me fait penser à la réflexion d’un formateur qui décrivait un outil (en ligne de commande) et tenait ces propos : « l’outil machin est super puissant, il est tellement puissant que toutes les fonctionnalités ne sont pas documentées » 
hhahahhAHAHAHA comment je lui ai jeté des pierres :casstet:
[quote]LoneWolf> La compilation conditionnelle existe bien sûr sous VC++, d’alleurs de base tu as la possibilité de générer une appli « Debug » et une autre « Release » juste avec un clic :)… De mémoire tu as des macros de type ASSERT( condition ) qui n’existerons que dans la version Debug.[/quote]Ah sympa ca.
[quote]L’environnement VC++ est le plus puissant et ergonique que j’ai vu jusqu’ici (ceux qui pensent que emacs est puissant passez votre chemin SVP )[/quote]Ouais. Personnelement, j’en suis revenu, de VC++: Deja 1, le Hello world de 200 lignes, ca fout les boules direct.
Ensuite, pour compiler un programme avec une librairie particuliere avec gcc, tu dois etre explicite, genre -I/usr/local/include/canna -L/usr/local/lib -lcanna (Librairie de gestion du japonais, c’est juste un exemple hein :))
Avec VC++, tu rajoute les repertoires, tu compiles. ld error. Tu bricoles, bidouille… RIEN. RAH EUH. Tu reboot et ca marche (quoi que la premiere fois, ca marchais pas). FAIS CHIER!
Je dois pas etre doue, avec les interfaces graphique a clickodrome, je crois.
LoneWolf
Vive la compilation explicite.
c0unt0> mouaif mais bon, le code est mixte C/C++ avec une grande utilisation de la STL, alors ce n’est pas seulement « j’alloue de la mémoire et je bricole autour »
LoneWolf> La compilation conditionnelle existe bien sûr sous VC++, d’alleurs de base tu as la possibilité de générer une appli « Debug » et une autre « Release » juste avec un clic :)… De mémoire tu as des macros de type ASSERT( condition ) qui n’existerons que dans la version Debug.
L’environnement VC++ est le plus puissant et ergonique que j’ai vu jusqu’ici (ceux qui pensent que emacs est puissant passez votre chemin SVP )
[quote]pour les debordement et les pointeurs aux fraises si :
avec un alloca maison tu peux faire des trucs genre et apres regulierement tu peu checker tes gaurdband, voir si elles sont en bonne etats, ou pas…
pareils pour les fraises : si tu remplis la memoire non alloue (ou fraichement alloue) (ou fraichement libere) avec un truc bien debile genre fcfcfcfcfc ou cdcdcdcdc tu peux faire apparaitre pas mal de truc…
en meme temps : c vrais c chiant :)[/quote]
C’est chiant, et au final, tu utilises plus de memoire que prevu, vu qu’a chaque allocation, tu alloue aussi sizeof(guardband)*2. En tant qu’ancien electronicien tournant sur 68HC11 avec 16Ko de memoire, je te dis: NON! ^^;;
Oui bon d’accord, maintenant, on a plein de memoire, mais cette technique reste gourmande en ressources (ou alors, tu l’utilise que pour debugger, mais ca peut lourdingue a gerer… Ca existe, la compilation conditionnelle, avec VC++? MakeFile rulez ^^;; )
LoneWolf
Osons l’optimisation memoire.
pour les debordement et les pointeurs aux fraises si :
avec un alloca maison tu peux faire des trucs genre et apres regulierement tu peu checker tes gaurdband, voir si elles sont en bonne etats, ou pas…
pareils pour les fraises : si tu remplis la memoire non alloue (ou fraichement alloue) (ou fraichement libere) avec un truc bien debile genre fcfcfcfcfc ou cdcdcdcdc tu peux faire apparaitre pas mal de truc…
en meme temps : c vrais c chiant
Purify, ou l’implementation open source de la chose, est ton ami:
http://developer.kde.org/~sewardj/
Enjoy.
LoneWolf
Il suffit de connaitre le truc™ Ma sorciere bien aimee.
Ouais ouais c0unt0 je pratique cette méthode surtout lorsque j’ai besoin de perfs mais là je cogne dans du code qui a été écrit sur plus de 10 ans … alors bon, on ne peut pas tout refaire, hein
Dans mon cas, le changement de méthode d’alloc/free ne changerait rien car j’ai sûrement à faire à un débordement mémoire :casstet: ou un pointeur aux fraises… pffff…