Discussion :

[Clad3]

Bonjour à tous .
Dans le cadre d'un projet conséquen il parrait difficile de ne se passer totalement d'une gestion de la mémoire . Je me demande comment vous y parvenez, je serait surtout intéréssé par les libraries que vous utilisez ( si c'est le cas ... ), les "règles d'or" que vous respectez ...

Si ca peux aider, je compile sous windows avec VC++ 2003 , mais je tiens à ce que mon programme soit portable .

Sinon , j'ai vu qu'une librairie revenait pas mal de fois, le mémory manager de Fluid's Studio, vous en pensez quoi ? J'ai du mal à trouver un article conséquent dessus, détaillant son utilisation, ses pours et ses contres ...

Merci .

[aziz jim]

En ce qui concerne la gestion de la mémoire, j'éspère que ceci vous aidera:


http://haypo.developpez.com/article/halloc/

[ash.ice.loky]

Salut Clad3,

La gestion de la mémoire, tout un programme en C++
Je n’utilisais aucun gestionnaire jusqu'à ce qu’il me soit confié
De gros projets dans un cadre plus professionnel ou la tu ne dois pas te louper.
Je me suis alors dit faut ci mettre et depuis je ne ferais machine arrière pour rien.

A mes yeux il y a 2 outils indispensables :
- le Gestionnaire de mémoire (surcharge de new, delete, new[] et delete[])
- les pointeurs intelligents (donc plus de delete lol)

Je précise tout de suite que je possède ma propre version pour chacun de ces outils
Et que je ne peux donc pas te renseigner sur tel ou tel lib.

Le gestionnaire de mémoire :
- SUPER
- Tu inclus dans tous tes fichiers un petit entete GESTIONNAIRE_MEMOIRE.h
- Dans ton fichier principal (avec le main) tu
- #define ACTIVE_GESTIONNAIRE_MEMOIRE

Et c’est tout. Le reste est auto, et te sort en un fichier avec les fuites, libérations, et tout ce qui va avec.

Bien entendu cette méthode est valable pour mon gestionnaire mais ca doit être un peu partout pareil et surtout tu vois la simplicité du truc.

Une fois la version finale développé, tu remplace par :
- #define DESACTIVE_GESTIONNAIRE_MEMOIRE

Et voila une version optimisé (sans les tests donc).

Les pointeurs intelligents :
La j’avoue ne pas trop accrocher, j’ai mes propre pointeur intelligent, compatible Polymorphisme et STL mais ne gère pas les tableaux, mais tu les remplace par les vector
Donc pas de problème de ce coté la.

Le principal ennui est le remplacement des problèmes de new/delete par celui des
Compatibilité. Par exemple tu souhaites faire un gestionnaire de ressources, alors tu dois utiliser un pointeur différent car map< string, PoiteurIntel<ressource> >, par exemple ne libère jamais car par tu as déjà ton compteur a 1.

Et surtout tu te retrouve avec un code assez lourds avec des PoiteurIntel<XXX> partout, dans les définitions de méthodes, les déclarations, bref, tu ne doit plus avoir de * sous prétexte de mettre tes pointeurs dans le mur.

Du coup je suis pas trop pour cet outil.

[Luc Hermitte]

Les gestionnaires de mémoire pour débugguer, blinder et valider la gestion manuelle de la mémoire, pourquoi pas.. Ils servent aussi pour optimiser (mise en oeuvre de pools de buffers).
Par contre, je ne trouve pas que cela aide particulièrement à gérer la mémoire.

Au contraire des pointeurs intelligents. Ces derniers correspondent à l'application du RAII à la gestion de la mémoire. Et le RAII, c'est l'idiome, qui en C++, permet de gérer simplement des ressources dans le contexte où des exceptions peuvent survenir. Le gestionnaire de mémoire n'aide en rien du tout sur ce point critique.

La criticité du point ne correspond qu'à ma propre expérience. Au début le client teste l'outil dans les cas nominaux, puis il s'amuse à valider dans les cas à la noix (perte de réseau, plantage de process critiques à divers moments, réception de télémétrie corrompue, ...)
Là, la gestion des exceptions a intérêt à être carrée. Et le RAII aide bien pour cela.

[JolyLoic]

Je ne sais pas trop ce que vous entendez par "gestionnaire de mémoire", mais au cas où ce ne soit pas ça, je voudrais juste signaler qu'il existe aussi des garbage collectors en C++.

[Luc Hermitte]

J'ai repris la "définition" d'ash.ice.loky -> une couche qui détourne new/delete.

[tut]

Puisque tu demandes un retour d'expérience, eh bien en ce qui me concerne, je n'utilise aucun gestionnaire de mémoire.
Je me sers de deux trucs :
- le debugger de Visual qui indique les fuites mémoire quand tu fermes l'appli (à condition d'inclure systématiquement une macro au début des fichiers sources, qui remplace le new par un new de debuggage). Il peut t'indiquer la ligne et le nom du fichier ou il y'a eu l'allocation non désallouée. Tu peux aussi poser un point d'arrêt à l'endroit où l'allocation est réalisée, si jamais il ne trouve pas la ligne et le fichier.
- j'essaye de respecter une règle d'or, certainement discutable mais il faut, je pense, en fixer une : "celui qui alloue désalloue aussi". Si tu préfères, la classe qui fait un new, doit aussi faire un delete. Bon, ce n'est pas toujours possible ni souhaitable suivant les pattern mis en application, mais quand je ne sais pas comment faire, je me raccroche à cette règle.

J'essaye avant de livrer une nouvelle version de mon logiciel de me réserver un peu de temps pour traquer les fuites. Je l'ai mis dans mes tests de non-régression, c'est important surtout si tu as des éxigences de sureté de fonctionnement.

Avec cette technique on peut arriver à s'en sortir, même sur des logiciel relativement important (pour info, j'utilise cette technique sur un logiciel qui fait actuellement 250 000 lignes de code).
Mais, peut-être qu'en utilisant des outils plus avancés, cela serait plus efficace.
Disons que j'aime bien mon approche, car elle m'a permis de détecter quelques bugs couillus AVANT qu'ils ne se déclarent, et elle donne l'impression de mieux maîtriser ce qui se passe, par rapport à une approche "Garbage collector".

Enfin, ce n'est que mon point de vue.

[Médinoc]

"celui qui alloue désalloue aussi"

Moi, je l'applique aussi pour un autre principe, qui est qu'une classe/bibliothèque C exportant une fonction qui alloue quelque chose a grand intéret à exporter une autre fonction qui désalloue (pas vraiment pour les objets, mais quand on retourne un tableau par exemple)
D'autant que sous Windows il y a 4 ou 5 méthodes d'allocation (hormis pour les objets), dont certaines deprecated qui ont leurs avantages et leurs inconvénients. Et bien entendu, toutes sont incompatibles entre elles.

On s'en rend compte assez facilement pour certaines fonctions: strdup() nécessite un free(), StrDup() et FormatMessage() nécessitent un LocalFree() (mais de nos jours, LocalAlloc() est déconseillé), les méthodes recommandées étant les fonctions HeapAlloc() et VirtualAlloc().
Alors plutôt que de préciser dans l'aide, j'exporte une fonction qui détruit ce que les autres fonctions ont créé...

[themadmax]

Pour ma part je n'utilise seulement l'outil fournir avec VisualC qui est bien infuché de me dire les lignes ou sont intencié mes fuites de memoire. J'ai vue 2 ou 3 petite chose sur le net qui permet pareil en surchargant le new, de stoquer les fuite dans des vecteurs puis d'affcher un rapport precis en fin d'execution.
Pour les smart pointer (voir la lib boost) c'est assez lourd à metre en place.
Sinon j'ai tester il y a peut de temp DevPartner de Compuware, integrable à VC.Net. Attention c du gros du tres gros il faut une becanne de ouf. Mais il peut te permettre de detecter plein de fuite (Allocation ressource, delete avec malloc...)

[Clad3]

Hum, j'ai du mal à faire un résumé dans ma tête, mais on va quand même essayer.

On a deux "problème" , le premier est de ne pas avoir de fuite de mémoire et de ne pas faire d'opération illégale vis-avis de celle-ci [ C'est ce problème qui m'interesse pour le moment ] . Le second étant de gérer correctement la quantité de mémoire disponible et de libérer les objets non utilisé ect... [ ex: GC ] .

Revenons à notre premier problème :

On a deux type d'allocation, sur le tas "heap" et la pile "stack". Seul les allocation sur le "heap" sont potentiellement dangereuse.

Pour éviter tout problème, une seule règle, peut importe comment on met en place un système la vérifiant, mais il le faut :

- Tout ce qui est alloué par un new, doit se voir suivre un delete correspondant quelquepart .

Maintenant il reste à voir comment on fait ca ... j'aime bien l'approche du " tout ce qui alloue, désalloue". J'aime bien aussi les smart ptr.

Concernant l'override des new/delete, ca ne permet que de traquer les fuite de mémoire, pas de les éviter. Je suis pas fan . Ca peut paraitre utopique, mais je préfère essayer de m'appuyer sur des mécanisme me permettant d'éviter d'avoir des erreurs, plutot qu'un me permettant de la localiser .
Au pire, je m'en remettrai au debuggeur de VC++ pour tracker la vilaine bestiole .

Enfin bon, je vais quand même continuer a regarder ce que donne les librairie d'overriding des new/delete, histoire de voir si il y en aurai pas une trés simple a utiliser et qui n'imposerai pas d'overhead trop gros ( surtout en mode release )
Merci pour vos interventions !

[Luc Hermitte]

Pour les smart pointer (voir la lib boost) c'est assez lourd à metre en place.

Dans le cas des smart-pointeurs de boost, il ne s'agit que de .h à déployer -- IIRC. Très simple à faire tant que tu ne compiles pas avec des ancêtres comme VC++ ou un vieux SunWSPro (ce que j'utilise au boulot )
Et c'est bien moins lourd à mettre en place que d'écrire et maintenir un code exception-safe en gérant explicitement à la main chaque delete. C'est sans commune mesure.

@Clad, Si ce n'est pas déjà fait, regarde la FAQ dans la section gestion de la mémoire et aussi surtout le point sur le RAII.

Enfin bon, je vais quand même continuer a regarder ce que donne les librairie d'overriding des new/delete, histoire de voir si il y en aurai pas une trés simple a utiliser et qui n'imposerai pas d'overhead trop gros ( surtout en mode release )

En général, les vérifications, ce n'est qu'en mode debug. Pas en release. Par contre, en release, on peut payer un chouilla plus pour mettre en oeuvre des pools de buffers qui ont pour but d'accélérer les allocations. Mais rien à voir avec la bonne gestion de la mémoire. Il ne s'agit que d'optimisation.
Sur le thème, cf. l'article d'Andrei Alexandrescu -> http://www.ddj.com/dept/cpp/184402039

PS: il y a aussi les "allocations" statiques et globales

[JolyLoic]

On a deux "problème" , le premier est de ne pas avoir de fuite de mémoire et de ne pas faire d'opération illégale vis-avis de celle-ci [ C'est ce problème qui m'interesse pour le moment ] . Le second étant de gérer correctement la quantité de mémoire disponible et de libérer les objets non utilisé ect... [ ex: GC ] .

C'est marrant, pour moi, le GC entre dans la première catégorie, et dans la seconde on retrouve plutôt des pools d'allocation.

Sur les GC, j'avais bien aimé http://www.open-std.org/JTC1/SC22/WG...2006/n1943.pdf écrit par une personne ayant justement mis en place depuis longtemps un GC utilisable en C++. C'est d'autant plus intéressant que si on regarde le GC le plus courant depuis peu en C++, à savoir celui que Microsoft fourni pour .NET, il y a des différences très importantes avec ce qui est évoqué dans ce papier, papier qui me semble bien plus intéressant pour le C++.